[RFC] CAM pass(4) patch for NVMe

[Jim Harris]

On Tue, Apr 4, 2017 at 7:54 AM, Warner Losh <imp at bsdimp.com> wrote:
> On Tue, Apr 4, 2017 at 8:30 AM, Chuck Tuffli <chuck at tuffli.net> wrote:
>> Hi
>>
>> I posted a patch on Phabricator[1] which adds IO pass-through support
>> for NVMe and would like some feedback on it. The bulk of the change is
>> pretty straight forward, but there was one part I'm not sure is the
>> best approach. The driver needs to know what type of command the
>> application is submitting in order to place it on the correct type of
>> NVMe queue. The patch uses bit 5 (i.e. 0x10) in the xflags variable of
>> the ccb header for this purpose. xflags was convenient to use, but
>> since other drivers don't use it, my guess is this is "the wrong way".
>> If it is OK to use xflags for this, cool, otherwise I'm open to
>> suggestions.
>
> Yea, one of the comments I posted to review... At the very least, it
> needs nvmecontrol uses different devices to distinguish between the
> different queues. I find this somewhat unsatisfying, but it works.
> nda, however, doesn't publish a transport level or sim level device
> that one could easily latch on to. The issue becomes one of security:
> If I can open nda0/pass0, can I control namespace operations for the
> drive? Download new firmware? etc. However, you can do all these
> things with other classes of devices today, so maybe that's not the
> biggest issue.

Would separate XPT_NVME_IO and XPT_NVME_ADMIN values work here instead?

>
>> As background, NVMe has two categories of commands: administrative and
>> NVM (sometimes referred to as "IO"). I don't think it is possible for
>> the driver to guess the command category based on the cmd bytes as:
>>  - the command opcode values alias. E.g. Flush (NVM) and Delete
>> Submission queue (Admin) use opcode 0x0
>>  - both categories have commands which use a non-zero Namespace ID
>> (like a LUN). so filtering on NSID wouldn't work
>
> In theory, you could use 0xffff as the NSID, since that's not a valid NSID.
>
> The current support of name spaces is a bit weak in nvme/nvd too. And
> it's even weaker in nda since I didn't have a multi-namespace drive
> until lately.
>
> So what are your goals with this work? I'm aware of another effort to
> improve the name space support in nvmecontrol which isn't going
> through nda. I'm also working on getting the nvmecontrol functionality
> moved over to camcontrol.
>
> Warner
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"