Re: NVMeoF and ctl

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
>