From nobody Tue Feb 08 00:31:38 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 083CA19B2F7A for ; Tue, 8 Feb 2022 00:31:53 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jt3q90J99z3kVg; Tue, 8 Feb 2022 00:31:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4BC973202239; Mon, 7 Feb 2022 19:31:41 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 07 Feb 2022 19:31:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=UEFs+vyuDeuQhj He5Tsq5tFst4++VMMl7FwwLRHlBGU=; b=E0ZVmoS7z0Hh+R+bRbeTiFMth9Pfg/ 3J2M0lM1EUMk1wpthFtpgjxUhhpl4QlXRu/Z7F+O5duNqCPD79gmy/3OJknNTkZw pPqpKujKZcE4+sVpGefnMwoIvEqqiDZqWHbTTXLGz/K2SeA76/d+pkblIFSbNTh8 vRsvfkeo47vRnruq4mwNkSTNt4g/ld6mvM0HIDq1boRfnUdi+3o+KXSS5HlhvfKw smDLEb8HAEEcPBP3Mx5HbdoggvcM1GaWt8YN36g+yEoe3p1sRp4yzyZFCffpMSPW H1Sw7XClAuqYJk4pKFWnhsOhOdhXTJ46evZ8qFKkSDe7Wm66SUL1AQFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=UEFs+vyuDeuQhjHe5Tsq5tFst4++VMMl7FwwLRHlB GU=; b=Wz1zZANW7wCBNEarSpTAE8TNV8BDUuIRbaUArsSCokNM/Snv2mhAzCwYu XMT8XH8u7PEYtriB1CWSZAZ5Q92QV0t3FoLldSWY20aCD/v/1VVqvHm2VbcZOQ2m oPgqRmo5owx4G2ChurwwbNJnm1814YMHSSrDR6uw8qrqscQFFdp+crqDPMjjLaI4 oipxwkqESQMsOLM03fqQzCE2bMIiia+UZ+yvqtSbyxuxe2kqmFqoJjy6WmpnNNkt JeT/iC36QGv8Q1XwbFseaCBwC3aXjw3y/2ONNJMF2356LPmzGGzPAuyGXmymHUqL WhMkHhnupzx9Y0XP9uGOGkCBgSnbQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheeigddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomhepufgtohhtthcunfhonhhguceoshgtohhtthhlsehsrghmshgt ohdrohhrgheqnecuggftrfgrthhtvghrnhepfeejgefgjefhgfdtjeevjeekgeevieelue ehjefgudetvefgtdetgffggefgvdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepshgtohhtthhlsehsrghmshgtohdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 7 Feb 2022 19:31:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: NVMeoF and ctl From: Scott Long In-Reply-To: <694eabe2-e796-ebdc-b3f1-eff8f8fc1b24@FreeBSD.org> Date: Mon, 7 Feb 2022 17:31:38 -0700 Cc: Ken Merry , Alexander Motin , =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= , "scsi@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <694eabe2-e796-ebdc-b3f1-eff8f8fc1b24@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4Jt3q90J99z3kVg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm2 header.b=E0ZVmoS7; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Wz1zZANW; dmarc=none; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 64.147.123.25 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-4.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[samsco.org:s=fm2,messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[scottl]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[samsco.org]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[scsi] X-ThisMailContainsUnwantedMimeParts: N CTL stands for =E2=80=9CCAM Target Layer=E2=80=9D, but yes, it=E2=80=99s = a Periph and it=E2=80=99s deeply tied to SCSI protocol, even if it=E2=80=99= s mostly transport agnostic. I guess the answer to your question = depends on the scope of your contract. It would be ideal to refactor = CTL into protocol-specific sub-modules, but that might take a = significant amount of work, and might not be all that satisfying at the = end. I=E2=80=99d probably just copy CTL into a new, independent module, = start replacing SCSI protocol idioms with NVMe ones, and along the way = look for low-hanging fruit that can be refactored into a common library. Scott > On Feb 7, 2022, at 5:24 PM, John Baldwin wrote: >=20 > 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). >=20 > A question I have about this is if it makes sense for NVMeoF target = support to > make use of ctl? =46rom 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? >=20 > --=20 > John Baldwin >=20