标签：管理 数据 open 替代 导出 drivers system ssd nvme
对于大部分人来说，NVMe over Fabrics（简称NVMf）还是个新东西，因为其第一个正式版本的协议在今年6月份才发布。但是这并不影响人们对NVMf的关注，因为这项依托于NVMe的技术很可能继续改变存储市场格局。
NVMf的贡献在于提供除PCIe外访问NVM的另一个途径-Fabrics，并且将fabrics链路在latency上增加的overhead维持在10us以内。来自NVMf spec的一张图清晰的展示了它的野心，围绕着NVMe的战场再一次扩大了。
提供fabrics途径后，可以在其他节点直接访问NVMe设备，那么最基本的应用就是替代传统的iSCSI，在闪存系统中导出NVMe。
NVMf以NVMe为基石，适配Fabrics场景，新增或删减了的一些Command、概念。
1，Host，Target和Transport
client端称作Host，处理client请求的部分称作Target端（连接物理NVMe设备），Host和Target之间使用NVMe命令交流。Transport是连接Host和Target的桥梁，可以是RDMA或者FC。在Fabrics传输过程中，NVMe命令会被相应的Transport代码封装（Capsule）和解析。
2，NVMe Subsystem，NVMe Namespace和Port
一个Subsystem就是一个NVMe子系统，Subsystem在target端，Host可以申请连接某个target的Subsystem。一个Port代表一个Transport资源。Subsystem必须和Namespace，Port建立关系，但是他们的联系又是很灵活的：即一个Subsystem可以包含多个Namespace，一个Namespace可以加入多个Subsystem，一个Port可以放入多个Subsystem。如下可以将一个NVMe Namespace放入两个Subsystem中形成Fabric多路径配置。
3，NVMe Subsystem中的NVMe Controller
在NVMe Subsystem中，NVMe Controller是一个虚拟的概念，但是具有NVMe协议规定的属性（如部分NVMe寄存器，NVMe Queue和处理NVMe Command）。当一个host接入Subsystem后，就会创建一个Controller对象。那么如何处理NVMe寄存器的访问呢？这就要涉及到NVMf定义的几个Command。
4，NVMf新增和删减Command
在NVMf下，Host和Target之间的传输舍弃了Doorbell的设计，删除了NVMe Queue Create等Admin Command。NVMe Queue的创建在构建Controller后就已经完成了。
NVMf协议新增加的Command如下图，其中Property用来访问NVMe Controller寄存器（仅限于有限的几个寄存器，如Controller Configuration），Connect用来连接Host与Controller的NVMe Queue，Authentication则用于权限管理。
5，NVMe Command的传输方式
Host和Target间的NVMe命令可以在Transport封装时将I/O 数据置于NVMe Command（64Bytes）之后，或者使用SGL表示。如果是前者，则target直接从offset处读取数据，如果是后者，则需要通过RDMA read获取数据（Transport为RDMA的情况下）。虽然声称使用SGL，但是无论是SPDK还是Kernel 实现的Target在提交给物理设备的时候都会转换成PRP，所以目前的NVMe SSD还无需担心由于无法处理SGL请求导致的问题。
NVMf的推广很大程度上要依赖于其代码的实现，好在从Linux Kernel 4.8开始就被收纳，目前只有RDMA一种Fabric Transport。接下来我们看看内核态NVMf的代码框架。
Host端，主要是Host端代码和非NVMf模式下Local NVMe的处理。不管是Host端，还是Local的请求都会经过Linux blk-mq再下发到物理NVMe设备。当然，在经过Fabrics前，I/O请求会先被封装成NVMe Command格式。
Target端，实现了两种Transport（Loopback和RDMA），用户设置通过configfs进行。在收到Host端的I/O请求后，Target也是经过blk-mq下发到物理设备（其实是通过submit_bio向Host端的Local NVMe代码发起请求，类似于文件系统的方式）。
SPDK也加入了NVMf阵营，实现了Target端的代码。由于SPDK天然的优势，Target端的I/O请求可以直接发给物理Controller（Direct模式下），并且按照NVMf的规定将物理Controller作为NVMf独占，在I/O路径和框架上看起来更简洁。
不过，值得一提的是，无论是SPDK还是内核NVMf，从Host端过来的NVMe Command都要被Target代码解析成普通的I/O Request发给PCIe NVMe代码处理，所以NVMf下无论是NVMe Queue还是NVMe Command都是相对于Subsystem和host之间而言。
说明
本文最先发布于公众号《存储技术最前线》，欢迎关注获取最新NVMe技术和资讯
参考资料
1, NVM Express over Fabrics Revision 1.0 spec
2, NVM Express Over Fabrics by Dave Minturn,Intel undle Openfabrics Alliance
3, Under the Hood with NVMe over Fabrics by Dave Minturn,Intel at SNIA forum
4, NVM Express Device Drivers by Uma M.Parepalli at FlashMemroy Summit
标签：管理 数据 open 替代 导出 drivers system ssd nvme
原文地址：http://www.cnblogs.com/rodenpark/p/6220519.html
