Date: Tue, 4 Apr 2017 09:01:01 -0700 From: Jim Harris <jim.harris@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Chuck Tuffli <chuck@tuffli.net>, freebsd-scsi <freebsd-scsi@freebsd.org> Subject: Re: [RFC] CAM pass(4) patch for NVMe Message-ID: <CAJP=Hc90VvTUWrRw9DkhswvvcJjx=Aso-3e9FXS0126=fQ-Acw@mail.gmail.com> In-Reply-To: <CANCZdfoTroqgvtwW8fJyquf063cJfdriUfyOqNOy=rx8wM=Qsg@mail.gmail.com> References: <CAM0tzX2b1NU=y1Vr=XeU63D5=3FJVHPD9e9fLSFaNvQhLtQa=A@mail.gmail.com> <CANCZdfoTroqgvtwW8fJyquf063cJfdriUfyOqNOy=rx8wM=Qsg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 4, 2017 at 7:54 AM, Warner Losh <imp@bsdimp.com> wrote: > On Tue, Apr 4, 2017 at 8:30 AM, Chuck Tuffli <chuck@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP=Hc90VvTUWrRw9DkhswvvcJjx=Aso-3e9FXS0126=fQ-Acw>