NVMe-oF RDMA vs. TCP延时测试对比:端到端SPDK的意义

前不久看到一篇《NVIDIA BlueField 再创 DPU 性能世界纪录》的新闻,该测试环境是2台服务器,每台各安装2块NVIDIA Bluefield-2 DPU,形成4条100GbE以太网直连,两端分别跑NVMe-oF Target(存储目标)和Initiator(主机端)。

测试结果包括TCP和RoCE(RDMA)两部分,上图是第一部分。我们看到,用户态SPDK to SPDK的512Byte小块读测试达到了41.5M(超过4100万)IOPS;Linux 5.15内核的FIO测试只有不到SPDK一半的性能,应该是CPU被I/O中断跑满了,4.18内核则又低了不少。

作为块存储设备,512B IOPS性能基本上只对++Optane(傲腾)SCM++介质有意义,比如Intel P5800X的4K随机读写、512Byte随机读IOPS指标分别为是150万和460万。对于传统NAND闪存SSD来说,小于4KB的IOPS通常也不会更高了,因为闪存页面大小一开始就是4KB(先进制程NAND的物理页面大多在8KB-16KB)。

另一点值得注意:在NVIDIA新闻的测试平台介绍中,并没有提到用的什么持久化数据盘,也就是说该测试应该是用DRAM内存模拟块设备来跑网卡的极限性能,没有提到随机访问那就是顺序IO了。

在4KB数据块测试中,用户态与内核的差距就没有那么大了,因为网卡的吞吐量快跑满了。其中SPDK to SPDK的读达到了345Gb/s,读写双向则是431Gb/s。

如果换用RoCE,Bluefield的512B小块IOPS,以及4KB双向带宽比TCP有进一步的提升。不过在这个新闻稿中没有提到延时数字,于是我又把https://spdk.io/doc/performance_reports.html 网站上Intel的测试报告翻了出来。

端到端SPDK延时只有5µs:这个数据落盘了吗?

上图引用自《SPDK NVMe-oF RDMA/TCP (Target & Initiator) Performance Report Release 21.10》这2份文档。Intel是用一台配有16个P4610 SSD的服务器跑NVMe-oF Target,前端通过2个CX-5 100GbE网卡直连2台NVMe-oF Initiator服务器。

这个测试环境,比前面NVIDIA那份新闻稿更接近真实应用。不过当我看到下面的延时数据时,还是怀疑这部分测试的IO是否都落盘(SSD)了?

上面图表是我从Intel报告的"Test Case 3: Linux Kernel vs. SPDK NVMe-oF RDMA Latency"中整理的数据,用iodepth=1和单任务能测出最短延时。

可以看出,使用Linux内核的NVMe-oF Initiator和Target测试,延时在16-18µs之间;如果只是把后端存储换成SPDK Target,延时降低到13µs多;只有IO负载请求和目标端都使用SPDK才能达到最短的5µs左右。

显然NAND闪存SSD应该跑不了这么快。可以参考下我在《++NVMe-oF三种协议(FC、RDMA、TCP)对比:成败不只看性能++》中对比的数字(如下图)------这个是包含SSD延时在内的。

图注:"不同NVMe-oF协议的延时对比主要看低并发/队列深度时。纯软件NVMe/TCP接近100微秒了;而RoCE只有大约30微秒;FC-NVMe在50微秒左右,TCP-Offload甚至比它还要稍好一些。"

记得在几年前的《++SPDK实战、QoS延时验证:Intel Optane P4800X评测(5)++》一文中,我测试过当时唯一能达到10µs以内延时的SSD(DRAM内存盘除外)。

当年我用FIO测试P4800X在Linux Kernel下的随机读延时为14.2µs,而用户态的SPDK则可以跑到6.49 µs。如果是NAND闪存SSD,正常应该在100 µs左右的水平;随机写有可能会较短,因为固态盘上有Cache。

在Intel报告的Latency测试配置部分,我认为是找到了答案(如果不正确的话,请读者朋友纠正我):bdev_null_create应该是创建了一个并不在SSD上的"空"设备,即等于10240MB的内存盘。为了对比测试NVMe-oF网络的延时,在这一段如此操作倒也合理。

同时我还对比了另一份本地盘的测试报告《SPDK NVMe BDEV Performance Report Release 21.10 》,其中延时数据如下:

上面这个才是实打实的NAND闪存SSD延时水平------我们看到Linux内核libaio引擎平均随机读延时为85µs,SPDK BDEV和io_uring则能够分别降低到71µs和73µs。

SPDK对NVMe/TCP网络延时贡献有限

这个图表整理自Intel报告的"*Test Case 3: Linux Kernel vs. SPDKNVMe-oF TCP Latency"*部分数据,可以看出NVMe/TCP的延时水平,以及SPDK在这里的价值。

本文主要就写这么多,下面给出本次阅读理解的结论:

1、++SPDK的最大价值,依然是用户态Pooling,相比传统内核IRQ I/O能够显著节省CPU资源;++

2、++当使用Linux Kernel I/O时,NVMe-oF RoCE网络的延时约在16-18µs;NVMe/TCP则达到30++ ++µs左右,并且TCP网络混合读写的延时还有增大;++

3、++在Target/Initiator端到端SPDK配置下,NVMe-oF RoCE延时降低到5µs左右;NVMe/TCP与内核态I/O相比也有改善,但仍在20µs以上;++

注:除非特别说明,以上关于NVMe-oF延时的数据,都没有将SSD延时考虑在内。

简单来说,NVMe/TCP比基于RDMA和FC的NVMe-oF网络延时高,这是许多人都知道的。端到端SPDK能够降低延时,而且这种贡献在RoCE网络下表现更好。

附:SPDK(即IRQ vs. Polling)性能提升原理示意图

上面这个是经典的Polling模式,会把一个CPU核心长时间占满。

后来又有人提出了Hybird Polling(混合轮询),在没有I/O时可以插入Sleep睡眠来降低CPU负载。

参考资料

NVIDIA BlueField 再创 DPU 性能世界纪录

https://spdk.io/doc/performance

相关推荐
deeper_wind4 小时前
keeplived双击热备配置
linux·运维·网络
技术猿188702783517 小时前
实现“micro 关键字搜索全覆盖商品”并通过 API 接口提供实时数据(一个方法)
开发语言·网络·python·深度学习·测试工具
zyhomepage8 小时前
科技的成就(六十九)
开发语言·网络·人工智能·科技·内容运营
Arva .8 小时前
HTTP常见误区
网络·网络协议·http
创思通信9 小时前
4G模块 A7670发送英文短信到手机
物联网·网络协议·信息与通信
Synfuture阳途10 小时前
终端安全管理系统为什么需要使用,企业需要的桌面管理软件
网络·安全
LUCIAZZZ11 小时前
高性能网络模式-Reactor和Preactor
java·服务器·开发语言·网络·操作系统·计算机系统
k *11 小时前
网络编程-tcp连接:服务器与客户端
服务器·网络·tcp/ip
云云32111 小时前
亚矩阵云手机:破解 Yandex 广告平台多账号风控难题的利器
网络·科技·线性代数·智能手机·矩阵
枷锁—sha11 小时前
【DVWA系列】——File Upload——High详细教程(webshell工具哥斯拉)
网络·web安全·网络安全