Date: Tue, 4 Apr 2017 10:21:29 -0700 From: Chuck Tuffli <chuck@tuffli.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-scsi <freebsd-scsi@freebsd.org> Subject: Re: [RFC] CAM pass(4) patch for NVMe Message-ID: <CAM0tzX0r3VrypNqW0D%2BQRJPO62ogKo1_o3eNg%2BKAYa=yBRMEKQ@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. > >> 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. Hmm, I think any value greater than zero is valid according to the spec (note that 0xffffffff has a special meaning). Certainly, devices won't support NSID values above their published Identify Controller.NN (Number of Namespaces) value, but hijacking the NSID value to specify the NVMe queue seems problematic as there are Admin commands which require 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. I'm working on a tool to gather SMART information and have been using CAM pass for ATA and SCIS. Having pass support for NVMe too would simplify the code and seemed like any easy addition seeing as how you'd already done all the heavy lifting. --chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM0tzX0r3VrypNqW0D%2BQRJPO62ogKo1_o3eNg%2BKAYa=yBRMEKQ>