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之后的版本。