Date: Mon, 7 Feb 2022 21:48:06 -0500 From: Alexander Motin <mav@FreeBSD.org> To: Scott Long <scottl@samsco.org>, John Baldwin <jhb@FreeBSD.org> Cc: Ken Merry <ken@kdm.org>, =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= <trasz@freebsd.org>, "scsi@freebsd.org" <scsi@FreeBSD.org> Subject: Re: NVMeoF and ctl Message-ID: <2cf0c467-6bb6-55c0-586d-54ffec559c78@FreeBSD.org> In-Reply-To: <EB0FE720-A845-44CE-9C51-80F7C995CFE1@samsco.org> References: <694eabe2-e796-ebdc-b3f1-eff8f8fc1b24@FreeBSD.org> <EB0FE720-A845-44CE-9C51-80F7C995CFE1@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I feel that would we subtract SCSI out of CTL, there would not much left, aside of some very basic interfaces. And those may appear benefitting from taking different approaches with NVMe's multiple queues, more relaxed request ordering semantics, etc. Into recent NVMe specifications they've pumped in many things to bet on par with SCSI, but I am not sure it is similar enough to not turn common code into a huge mess. Though I haven't looked what Linux did in that front and how good idea it was there. On 07.02.2022 19:31, Scott Long wrote: > CTL stands for “CAM Target Layer”, but yes, it’s a Periph and it’s deeply tied to SCSI protocol, even if it’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’d 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 <jhb@FreeBSD.org> wrote: >> >> 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 >> > -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2cf0c467-6bb6-55c0-586d-54ffec559c78>