[RFC] CAM pass(4) patch for NVMe

[Chuck Tuffli]

On Tue, Apr 4, 2017 at 2:04 PM, Jim Harris <jim.harris at gmail.com> wrote:
> On Tue, Apr 4, 2017 at 1:50 PM, Warner Losh <imp at bsdimp.com> wrote:
>> On Tue, Apr 4, 2017 at 2:48 PM, Chuck Tuffli <chuck at tuffli.net> wrote:
>>> On Tue, Apr 4, 2017 at 11:13 AM, Warner Losh <imp at bsdimp.com> wrote:
>>> ...
>>>> Fair Enough. I'd thought 0xffff was the magic number :). However, you
>>>> raise a good point.
>>>>
>>>> Grep tells me all the xflags are actually unused. So we could use it,
>>>> but after chatting with Scott Long, I'm not sure that we should.
>>>>
>>>> However, I think Jim's idea of having a separate command for commands
>>>> for the I/O queue and commands for the admin queue might be the better
>>>> part of valor here. I'd initially read Jim's mail as use #defines for
>>>> the xflags values, but that's not at all what he was saying.
>>>>
>>>> The code change would be a bit bigger, but not by a lot. It's super
>>>> easy to add new XPT_ function code.
>>>
>>> OK, I'll head down that path and add a new XPT opcode XPT_NVME_ADMIN
>>> and helper macro cam_fill_nvmeadmin() which would be used for Admin
>>> commands. The existing XPT_NVME_IO would be used for NVM/IO commands.
>>> Both opcodes would use the ccb_nvmeio structure unless there are
>>> objections .... ?
>>
>> Seems reasonable to me.
>
> Me too.

OK, v2 of the patch is up using the new XPT op-code for admin commands
instead of the original xflags hack. I tried a couple of passthru
commands and it seems to work.

--chuck