From nobody Tue Feb 08 00:24:45 2022 X-Original-To: scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BEDE819AEDCA for ; Tue, 8 Feb 2022 00:24:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jt3g353W1z3hhX; Tue, 8 Feb 2022 00:24:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644279887; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=vGYPHW5Rmr0vHDLZLa/aP0ZwVFnOaoCdHx0sbY2jhe8=; b=yxB6oGqp+pWIGGRoy8/U6vlCn/Ti3e22bgfC9AtKYRjD/UcTPldVxL/luSg0aH1EOjF6Fr rHUBSKuGYjk2WzYTPR5nDtIB6lzEwMRhT80wonQNZucEfeHk0rbOoQyq7Byc6qxzI7dQlO VERqC5LFiIYlE+Rqjlna4XhTClQoiS/66vO23NBELZoCfTfEhGAVVGNZaf0K/iL4TO53lY Rz3/LCSBr/HhwxqF6gycEPLMYPSL8/0Rzn7FTDX3grFpr2TIoJ/TTRusSB/RxJpQ2SZjxI WKaGSGt1YaZgR8akbpejHAAxXm+izMhOJ8FB+LlA7fncrLGItRiM+mydyFWHTA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id F40141EF9; Tue, 8 Feb 2022 00:24:46 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <694eabe2-e796-ebdc-b3f1-eff8f8fc1b24@FreeBSD.org> Date: Mon, 7 Feb 2022 16:24:45 -0800 List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US From: John Baldwin To: Ken Merry , Alexander Motin , =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= Cc: scsi@FreeBSD.org Subject: NVMeoF and ctl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644279887; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=vGYPHW5Rmr0vHDLZLa/aP0ZwVFnOaoCdHx0sbY2jhe8=; b=i7S2YmuKkJK4wzlPDZDoFZeDxFRuau4+jeYYKZH5oTHFRtl5up4LdLLcPvrD2qF7bXeRo2 7i2t73uwNsWeapdnsbDupSNE4bBooqltyorRK1ymRiXQjx2EDqLrpzeJ6OJZaq17bNmmui dsRw0OcaX+1TlIEAI8KsSHdtTZKdLlyzVK1tigK7908KMmptOWeYuCouNdYwfgZwLqDmlZ VS47aN8/rhbLj0sYUqqr8324U7lsjaKXqwE/eFuFhhwxGlBv17QzJ20k+aWVitMog4ChZu lXlewqvxsxOv5r4JjYVUp+rUa8cSx5Qb3Up+V56i0hzWulzdCX0hamiQT49NWA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644279887; a=rsa-sha256; cv=none; b=TzgYwdNgrfebhXNrTppTpa7eyxjrM7etnZLolIV4bvoikIoDuZEHzt1GTWDVMVwUmdgBtB 7T0NW03mS9EVCtJKDxHjjM13m9VehCr4++wH84B//UyJdu5/mg0VlYJ2shVXQoNTrYN0VZ w4hsRT0iIVZ1ydYKT8Bsr3xZHGuX9H04KSft89sGtMDHjXCcicqm3ePrEXhMKN+uqdgJD3 r7Yn9Fqk07NmsmjjOosi+iPUHrjMJjesft9D4Yb1wce6FqvZpveXpNJypLLiCEBMRF+WO7 CYRUHb+X2ofu9/HycQiABUSzoBjXbqULETFF3kNvmgqB1e3c+R7YCeELvUpGiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N One of the things I will be working on in the near future is NVMe over fabrics support, and specifically over TCP as Chelsio NICs include NVMe offload support (I think PDU encap/decap similar to the cxgbei driver for iSCSI offload). A question I have about this is if it makes sense for NVMeoF target support to make use of ctl? From what I can see, the code in ctl today seems to be very SCSI specific including both in the kernel and in the userland ctld unlike the Linux target code which appears to support both NVMeoF and iSCSI in its ctld equivalent. Is the intention for there to be a cleaner separation here, and if so do you have any thoughts on what the design would be like? Or should NVMeoF just be its own thing separate from ctl and ctld? -- John Baldwin