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