NVME Fabric 是的未来

目前网上发布的NVMe Over Fabric 协议有两部分，一部分在NVMe 的标准协议1.2.1中，和over Fabric相关的都在一个单独的文件中。从这个单独放置的选择，可以看出目前的这个协议还是比较初级的，不能放到整体的协议里，因为现在还有很多待定的区域。        

就从这个独立的文件谈起吧，一开始就定义了目前阶段的限制，而且也是未来的工作方向。

严格1：1对应的SQ和CQ，不支持多个SQ对应一个CQ的设计。这就意味这个目前的实现的映射的功能比较弱。同时，因为1：1的方式，就不用担心请求乱序的问题。因为NVMe 本身没有流量控制实现，因此CQ的大小必须是可以所有的并发IO的总和。这个倒是可以理解，很多时候的流量控制是网络的功能，对于SCSI的over run和under run 的移植应该会在后面出现。元数据（如果支持的话）必须和数据在一起，目前不支持元数据和数据的分开传输的方式。 对应于EMC和HP的520字节的时代，目前4096Byte+64Byte的格式未来会是存储的主流吗？严格意义上讲，上面的东西还是偏向存储功能的多，对于大部分互联网的应用来讲都不是什么事。

接下来就是关键了，这里列举了和NVMe协议的区别，通过区别来了解两个标准，这样记忆最深刻， 俺记忆深刻的是：

 NVMe Over Fabric没有定义控制器生成一个host中断的方式，这部分由Host的HBA（其实就是各种传输卡）来自行处理。这样的好处就是可以个传输层拉开距离。对于建立CQ和RQ的时候，NVMe over Fabric不用原来NVMe的Admin的命令来实现，不用原来的ASQ，ACQ。这个其实不太理解，这个理论上应该可以做到通用的。不支持PRP，这个可以理解。这里就和NVMe over PCIe 有了区别，这里面就有另一个问题，

 NVMe over PCIe 和NVMe的区别在哪里？NVMe不就是NVM over PCIE 吗？

 下面这个图必须放：      

俺的理解，目前的主要区别是数据和命令的传输方式的不同的区别。这里面也就反馈了前面的一个重要局限， 因为数据和命令分开传输的情况，如果出现乱序怎么办？因此严格的1:1的配比就是这个原因。从而，也想起了Intel的DPDK的实现，数据和控制平面分开，从而提升数据传输的效率，想到Intel也不推荐跨CPU做操作就明白了，有得必有失。

后面这图，就是协议框架了：

 这个图里，个人觉得最关键东西在NVMe Transport这里，这是RDMA网络和NVMe结合的关键。至于Transport Binding 规范就是一堆如何发现，如何鉴权，如何建立链接的东东，这个熟悉ISCSI的基本上可以直接过了，没啥特殊的地方。

 第二章的封包和数据传输，基本上就是SQE和CQE以及SGL的这种组合，这个熟悉NVMe的大侠基本上也可以直接过。还有后面的命令集以及控制器的架构和发现，鉴权机制这些都不是俺关心的重点。重点是第7章的传输的定义。

 NVMe 的Transport必须保证每一对host和控制器之间的可靠的传输。呵呵，有没有TCP的感觉呢？这里的SQHD就有点像TCP里面的Sequence 和ACK ID了。    还有一个Keep Alive的定义，这个俺是不太了解了，之前SATA的OOB都没搞清楚，这个需要补课先。

 7.3 的RDMA的定义是需要反复来看的，RDMA的传输机制需要保证有序的封包的传输和数据的处理，这个处理是使用RDMA的QP 来实现对Admin和I/O command的支持。一个就是RDMA的封包和SQL的mapping， RDMA的传输支持SGL的数据块，SGL的最后区段以及键控的SQL的数据描述符，但是不支持在Host内存中的SGL，这就意味这必须有个转换或者可以用一个非标准的NVMe驱动也行，在NVMe的Fabric和管理封包中只有一个SGL的描述符，在I/O命令中可以有多个。

 看到这里，大家就明白了，RDMA和NVMe之前必须有一个转换，如何把RDMA的数据传输的QP和NVMe的SQ和CQ结合起来，这个实现方案协议是比较开放的，因此每家都可以自由发挥，作为FPGA厂家，Xilinx的实现如下图：    

     我会在下一章集中介绍Xilinx使用FPGA对于NVMe Over Fabric实现的加速功能，先在这个留个伏笔。多谢捧场。

     对于这个协议，基本上算是一个比较简单的框架，目前从协议制定参与方的来源来讲，可以看到RDMA的厂家和NVMe的厂家最积极。至于最终用户是否积极参与，这个要看大家实现方案的速度了，这里为自己的公司做个宣传，FPGA最擅长的领域就是在ASIC厂家没有准备好的情况下帮你出奇兵。