fabrics connect cmd with a non-zero reserved value

Engel, Amit Amit.Engel at Dell.com
Wed Jan 6 05:37:12 EST 2021


Hello, 
We see that when executing nvme connect cmd (Opcode: 0x7f Fabric Cmd)
The host is submitting the cmd with reserved filed set to non-zero value - which is out of spec.
Seems like this issue is not only for connect but also for other fabrics cmds.

Here is a packet capture for nvme connect :

    NVM Express Fabrics (Cmd)
        Opcode: 0x7f Fabric Cmd
        [Fabric Cqe in: 302]
        Reserved: 0x40
        Command ID: 0x0000
        Fabric Cmd Type: Connect (0x01)
        Reserved: 00000000000000000000000000000000000000
        SGL1
        Record Format: 0x0000
        Queue ID: 0x0000
        SQ Size: 0x001f
        Connect Attributes: 0x00
        Reserved: 00
        Keep Alive Timeout: 15000ms
        Reserved: 000000000000000000000000
    Data
        Host Identifier: f1aa9784-195b-4814-893d-44f90a6a92d9
        Controller ID: 0xffff
        Reserved: 000000000000000000000000000000000000000000000000000000000000000000000000...
        Subsystem NQN: nqn.2015-10.com.dell:dellemc-powerstore-23b5145591975EDFF2FE
        Host NQN: nqn.2014-08.org.nvmexpress:uuid:nc5199007
        Reserved: 000000000000000000000000000000000000000000000000000000000000000000000000...

0x40 value is corresponding to PSDT, in a normal (non-fabric) nvme cmd, PSDT field exists.
Do we expect for the same for fabric cmd?
If so, the spec can't mark the second byte of connect cmd as reserved.
Based on nvme spec:
"A reserved bit, byte, word, field, or register shall be cleared to 0h, or in accordance with a future extension to this specification"

Is this a real bug or a spec bug?

Thanks
Amit




More information about the Linux-nvme mailing list