fabrics connect cmd with a non-zero reserved value

[Sagi Grimberg]

On 1/13/21 4:34 PM, Sagi Grimberg wrote:
> 
>> 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?
> 
> We shouldn't be setting reserved bits. But from what I see, we zero the 
> nvme commands before setting it so this is strange to me..

OK, now I see the issue.

This appears to me this would be an issue with the spec. As the connect
data (like any command payload) is coming in the form of an sgl.

Adding Fred for this question.