NVMe over Fabrics 协议Discovery服务交互过程跟踪

Discovery服务过程跟踪

对于NVMe over Fabrics的subsystem，有两种类型：Discovery子系统和NVM子系统。这里介绍与Discovery子系统相关的交互内容（即：在Linux系统上使用nvme discover命令后的交互过程）。

Discovery子系统无Namespace存储空间，只响应相关的Fabric命令和Admin命令。这也就意味着主机与Discovery子系统只需要NVMe协议规格说明书中定义的Admin Submission Queue，而不需要IO Submission Queue。（之后描述Submission Queue简写SQ，描述Completion Queue简写CQ）。

参考NVMe over Fabrics协议规格说明书1.5.3 Capsules and Data Transfer章节中定义，交互内容格式如下边截图：

SQ请求使用的格式为：（其中前64字节为NVMe Command）

CQ回复使用的格式为：（其中前16字节为Completion内容）

Discovery子系统可以处理的命令包括Fabric命令和一部分Admin命令：

接下来按交互过程顺序来介绍。

1. 连接connect命令

此命令归属Fabric命令。

主机initiator端与target端Discovery子系统交互（注意：此connect命令前，需要已经存在Fabric链路作为SQ和CQ），由主机端发起connect命令。

参考下边抓包信息可以看到，connect命令包含了如下关键数值：

opcode为0x7f、命令ID为0、Fabric Command Type为0x01、QueueID为0、Queue最大值31、Keep Alive Timeout为0（不超时）。

在此交互的Capsule的数据内容大小占用1024字节，包含了主机标识、Controller ID、被请求的NQN、主机NQN，这4个主要内容。

本例子中，Controller ID填写了0xFFFF（65535），表示不指定controller。

允许连接的情况，回复如下内容：

其中Value: 1表示建立连接的controller的ID号为1。

备注：连接两种NVM子系统的过程是一样的，只是连接Discovery子系统时，请求的NQN是固定的nqn.2014-08.org.nvmexpress.discovery

2. 获取property属性(CAP)

此命令归属Fabric命令。

查询property属性（此属性对应PCIe场景下的register map for the controller），opcode用0x7f，Fabric命令类型为0x04（即表示property Get），如下示例中的查询property属性，Attribute为1表示读取8个字节，offset为0表示从property空间的偏移0开始读取。

从propert属性定义可以看出，此命令请求目的是获取CAP（Controller Capabilities）：

补充说明：对于Discovery子系统的控制器来说，只支持如下属性，其他的被Reserved：

对应的回应如下，此Response回应对应的是命令ID 14，查询出来的内容是CAP属性，值为十六进制ff 03 00 0f 20 00 00 00。

从NVMe规格说明书中查询CAP的8字节（64 bit）中各bit位表示的意思如下：

对照可以得出：

15:00对应的值ff 03，表示MQES队列深度可以支持1023（0x03ff=1023）。

23:16对应的值是00，表示CQR不是物理连续的，AMS仲裁机制支持也为0不支持。

31:24对应的值是0f，表示TO，从CC.EN使能到等待CSTS.RDY就绪的最坏超时时间。

37bit设置了1，表示CSS命令集支持，1表示支持NVM command Set。

3. 设置property属性(CC.EN)

此命令归属Fabric命令。

下边截图中，Attributes值为0表示设置4字节，offset是0x14，从前边截图Figure 30 Discovery Controller -properties可以得出是在设置CC（Controller Configuration）。

参照NVMe规格说明书，Controller Configuration对应bit位的意思，如下边截图Figure 78: Offset 14h: CC - Controller Configuration

本例子中的设置property属性目的是Enable使能controller。

回应的response如下：

4. 查询property属性(CSTS.RDY)

本次查询property属性时填写的offset偏移量0x1c，Attribute为0即读取4个字节，参照property属性表可知，本次查询的是CSTS（Controller STATUS）。

接下来，看回应response的内容：

对应查询命令ID 23的回复值是Value为1。

参照CSTS对应bit位的意思，可知，本次查询的CSTS.RDY为1，表示Controller已经ready。

5. 查询property属性(VS)

此命令归属Fabric命令，查询property属性中的offset偏移0x08位置，参照Figue 30即可得知查询的是version版本号。

回应此命令24的response内容为：

参照property属性表解释，可得知，Controller使用的NVMe协议版本是1.3.0。

附加说明：

对于主机端，查询此版本号，可以区分1.1.0版本及以后的版本，CAP中有NSSRC功能，此bit位的意思如下：

在linux系统中，主机就用查询版本号判断是不是1.1.0版本及以后的版本，来区分是否支持CAP.NSSRC功能。其他的当前还未看到主机端用版本区分功能的地方。

6. 获取property属性(CAP)

获取CAP，本次查询到的信息与使能前查询的到的信息一样。

这里出现了重复查询。本例子是使用的NVMe over TCP方式抓包的，是Linux系统下的操作，相关代码：

nvme_tcp_configure_admin_queue()

--> ctrl->ops->reg_read64(ctrl, NVME_REG_CAP, &ctrl->cap); //读一次

--> nvme_enable_ctrl(ctrl, ctrl->cap);

--> nvme_init_identify(ctrl);

--> ctrl->ops->reg_read32(ctrl, NVME_REG_VS, &ctrl->vs);

--> ctrl->ops->reg_read64(ctrl, NVME_REG_CAP, &cap); //又读一次

回应如下：

以上完成了主机与target端Discovery服务的Fabric连接过程。

接下来开始进行Admin Command处理分析。

7. Identify查询命令id-ctrl（Admin Command）

此命令归属Admin Command。

执行nvme id-ctrl命令的结果。

这里Identify查询命令，opcode为0x06，CNS字段填充0x01,表示查询controller Identify，注意：Discovery只定义了CNS为0x01的处理，其他情况未定义。

结合上边Figure 33: DiscoveryController - Identify Controller Data Structure回应内容解析，可知回应的内容大小为3072字节。

本例子操作时获取到的回应数据为：

Completion Queue Entry对应的16字节内容为：

接下来数据参照Figure 33分析：

Firmware Revision (FR): 5.0.7

Maximum Data Transfer Size (MDTS): 0 //固定填写0

Controller ID (CNTLID): 1

Version (VER): 1.3.0

Log Page Attributes (LPA): 0x04

Error Log Page Attributes (ELPE): 0x00

Maximum Outstanding Commands (MAXCMD): 0x00000000

SGL Support (SGLS): 0x00000000

NVM Subsystem NVMe Qualified Name (SUBNQN): 固定字符串

备注：

测试时使用了NVMe over TCP，分析截图使用了wirshark，需要wirshark 3.0.3之后的版本。