SPDK NVMe-oF TCP transport 目前优化的一些工作和方向

SPDK NVMe-oF transport 的实现自19.01正式发布以来，差不多快一年时间。在解决各种软件稳定性问题以及和Linux 内核互操作兼容的同时，也在性能优化方面不断进行一些尝试，这些尝试主要包括软件和硬件方向。在这篇文章中我们会集中讨论软件方面的一些优化方向以及目前SPDK NVMe-oF实现的一些工作（这些尝试最终会反映到SPDK github上的开源代码中）。鉴于很多SPDK NVMe-oF TCP的用户经常反馈一些性能的问题以及询问一些性能优化的方向。为此撰写这篇文章希望能回答一些众多开发者共同关注的问题。本文内容基于SPDK 这个master 版本， commit ID是：64bf0a6e8fac216907a6d6d9376840cbedec95b1一、SPDK NV

---

               

一、SPDK NVMe-oF TCP的主要性能瓶颈

如果经常关注SPDK官方 网站上文档那栏(http://spdk.io/doc)， 就会看到SPDK 社区会经常发布一些性能的报告。那么对于测试NVMe盘就会发现以下性能报告的数据：

1)   测试本地NVMe盘 SPDK单CPU core上的IOPS 性能差不多是同样配置情况下Linuxkernel 实现的6-10倍之间（使用perf工具）；

2)   测试远端NVMe盘 SPDK NVMe-oFRDMA target 单CPU core上的IOPS 差不多也是同样配置下Linux kernel 实现的6-7.5倍之间（固定CPU core 数目，测试不同连接数目>=16）， 参见 SPDK19.04 NVMe-oF RDMA Performance Report  Page 27-32.

3)   测试远端NVMe盘 SPDK NVMe-oF TCPtarget 单CPU core上的IOPS 数据只有同样配置下Linux kernel实现的2-2.8 倍左右（固定CPU core 数目，测试不同的连接数目>=16）, 参见 SPDK19.10 NVMe-oF TCP Performance Report Page 36-40.

我们可以看到使用RDMA 传输层，对于单CPU core上的性能损失很小，在某些连接NVMe SSD的测试场景下可以忽略不计(因为rdma的latency是以微妙计算的)，因为RDMA全称是Remote Directly MemoryAccess，所以在远程数据获取中，主要是具有RDMA功能的网卡参与操作，CPU额外的负担很小。但是使用TCP/IP 栈不一样，我们发现在使用TCP/IP栈的时候，其开销非常大。主要可以分为以下两类：

1. 用户态和内核态切换的代价。这个代价包括两类：

   1.系统调用的开销（System calloverhead）;

   2.SPDK 用户态程序和内核之间数据的交互，不能很好的实现zerocopy。当然如果使用Linux kernel 的NVMe/TCPtarget 实现，是不存在切换问题的。因为NVMe/TCP相关的数据和命令从网卡进来，直接通过内核的网络栈，然后送到NVMe的I/O 栈进行处理。所以在这一点来讲，内核是有一定优势的。当然内核的劣势在于本地NVMeI/O 栈不高效。

2. 内核态TCP/IP栈的开销。熟悉TCP/IP 栈实现的网络专家们一定非常清楚一个通过的TCP/IP栈的实现，在内核中的调用路径有多长，然后其中的同步的代价（在不同CPUcore之间）切换的代价有多大。相比RDMA 传输层来讲，TCP/IP的低效，绝对是影响性能的绝大瓶颈。其实这一点在我们评估SPDK iSCSI target 和Linux kernel的iSCSI target（LIO）也发现存在同样的问题。

基于以上的分析，开发人员应该可以意识到有以下的优化方向：

• 硬件方向 Offload NVMe TCP中的的数据传输。类似iSCSI中有iSER协议，NVMe TCP如果也有offload协议，那么就可以offload给RDMA, FPGA等。当然仅仅offload 到RDMA 意义不是很大，