天哪，DPU上的NVMe Over TCP到底该怎么搞？这简直是一场噩梦！

说实话，这事儿真的让人头大。你看现在的数据中心，CPU累得跟狗一样，为什么？主要原因是网络啊！存储啊！那些所谓的“高性能”协议，简直就是CPU杀手。你知道吗，处理10G的网络流量，大概需要4个Xeon CPU的核，这可是半个高端CPU的算力啊！太浪费了简直是暴殄天物。所以 DPU来了它就是来救命的，把那些乱七八糟的OVS、平安、存储统统从主机侧拉走，下沉到DPU上。听起来很美好对吧，不妨...？

但是现实往往比骨感还要骨感。DPU提供非常多的卸载功能，涉及到网络，存储和平安。在网络方面：DPU可以把整个虚拟网络比如OVS从主机侧下沉到DPU上。我们可以把整个OVS都下沉到DPU的ARM， 这样做的好处是简单快捷，只需要做一个OVS到ARM的移植就可以。 原来如此。 但是！注意这个但是这种方式需要耗用大量的ARM资源，而且性能也不一定太好。ARM核心也是资源啊，也是要吃饭的。你把OVS扔给它，它还要处理存储卸载，它不累吗？这就像让你一边做饭一边还要修车，谁能受得了？

所谓的“幻觉”与残酷的现实：NVMe-TCP的陷阱

NVMe-TCP，这玩意儿是个基于TCP的高性能流水线存储协议。它给你一种错觉，让你觉得远程的存储盘就像是插在本地主板上的本地存储一样。这就是所谓的“本地存储的幻觉”。 累并充实着。 呵呵，幻觉归幻觉，现实是很骨感的。这些存储盘其实都在远端，通过网络连接。为了维持这个幻觉，我们需要做大量的工作。

在NVMe-TCP中，每个存储队列都映射到一个TCP套接字。读写IO操作都有一个唯一标识符，称为命令标识符 。服务器可以无序处理CID，以允许小IO绕过大IO并提高性能。还有啊，每个PDU都受发送方生成并在接收方验证的应用层CRC保护。听起来很完美对吧？但是一旦你开始处理这些乱七八糟的PDU和CID，你的头就会开始痛，差不多得了...。

为了NVMe over TCP适配到TCP设备内存架构，我们简直要拼了老命。这不仅仅是把数据搬来搬去，这是在跟物理极限做斗争。DPU上Nvme Over TCP存储协议卸载的问题和解决方案，简直就是一本血泪史。NVMe over Fabric是一个相对较新的协议规范， 旨在使用NVMe和存储进行分解。

DPU也支持PKI，从而实现TLS握手协议的硬件卸载。你看，功能是挺多，但每一个功能都是个坑，至于吗？。

智能网卡支持NVMe-oF/TCP和NVMe-oF/RoCEv2作为Initiator， 和存储之间，来达到较高性能。但其实吧这些存储盘都是通过网络存储协议连接到远端的存储设备，这写网络存储协议以及相关的控制都是下沉到DPU上来完成的，CPU你。。

招人难啊！DPU存储卸载研发工程师去哪了？

说到这里我不得不吐槽一下招人的难度。现在找个靠谱的DPU存储卸载研发工程师简直比登天还难。岗位描述写得清清楚楚：负责DPU存储卸载方案的设计与实现， 参与SPDK/DPDK开源社区开发工作，负责DPU下一代存储方案的预研。职责要求一大堆：本科及以上学历， 精通C/C++语言，熟悉Shell, Python等脚本语言；计算机理论基础扎实熟悉x86/ARM架构，精通常用数据结构及算法；熟悉SPDK，有实际开发经验和upstream贡献者优先。

这还没完，有存储子系统性能调优经验者优先。有熟悉以下协议之一的优先：ROCE, Nvme over fabric等网络协议；熟悉mTCP/Sbosseastar，有用户态协议栈开发经验者优先；熟悉linux kernel block层及ext*/xfs/btrfs等常见文件系统者优先。你看这要求，简直就是想找超人。而且还得有kanzhun经验，这年头连看个简历都要这么卷了吗，一句话概括...？

眼花缭乱的产品：到底该选哪个？

市面上这么多DPU和SmartNIC，选哪个？这真是个让人头疼的问题。随便列几个大家看看， 物超所值。 别挑花眼。这表格做得我手都酸了希望能帮到你们这些还在迷茫中的工程师。

你看，AMD Alveo U45N网络加速卡与FPGA中的硬件加速引擎相结合的NVMe over TCP解决方案，如何密集型操作实现卓越性能，特别是相较于传统基于网卡的解决方案。还有啊， Alveo U45N集成了Arm Cortex-A72处理器，能够直接在卡上对各种虚拟化功能的支持， 在服务器侧引入智能网卡，可以将网络、存储、操...，哈基米！。

深入虎穴：DDP与CRC卸载的奥秘

好了回到正题。怎么优化？怎么实现飞跃式提升？关键在于卸载。但是 正如去年在“自主NVMe TCP卸载”会议上所介绍的那样，为了卸载NVMeTCP，但又不至于有完整卸载解决方案的缺点，引入了Linux内核上层协议直接数据放置卸载基础设施。这名字够长吧？读起来都拗口。

它为请求-响应ULP协议提供了和验证CRC，并在传输路径上计算CRC。这多省事儿啊！CPU终于可以歇会儿了，平心而论...。

重点讲解了virtio-blk和NVMe驱动， 以及iSCSI、Ceph和NVMe-oF协议栈在DPU上的卸载应用，旨在提高存储性能和平安性。本文介绍了DPU如何实现存储系统的硬件卸载， 事实上... 包括存储I/O接口卸载、远端存储的存储网络协议栈卸载以及本地存储的硬件I/O隔离卸载。你看，这一套组合拳下来性能不提升都难。

你看这段代码，虽然看起来乱七八糟的，但这就是TCP字节流的真实写照。请求流里PDU hdr和Req混在一起，响应流里Resp 2可能比Resp 1先回来。这就是乱序！这就是为什么我们需要DDP！

+Request TCP byte-stream: TCP请求字节流
+ +---------------+-------+---------------+-------+---------------+-------+
+ | PDU hdr CID=1 | Req 1 | PDU hdr CID=2 | Req 2 | PDU hdr CID=3 | Req 3 |
+ +---------------+-------+---------------+-------+---------------+-------+
+
+Response TCP byte-stream: TCP响应字节流
+ +---------------+--------+---------------+--------+---------------+--------+
+ | PDU hdr CID=2 | Resp 2 | PDU hdr CID=3 | Resp 3 | PDU hdr CID=1 | Resp 1 |
+ +---------------+--------+---------------+--------+---------------+--------+
+

别忘了那些乱七八糟的协议和细节

除了NVMe-TCP，还有NVMe-oF/RoCEv2。智能网卡支持这些作为Initiator，和存储之间，全靠这个。还有PKI，TLS握手协议的硬件卸载，DPU也支持。平安也很重要啊，虽然大家只关心性能，实际上...。

哎，对！ 还有HDS，TSO/UFO/LRO/GSO这些网卡卸载功能。这些都是老生常谈了但真的很重要。如果不把这些卸载了CPU还是得累死。以网络协议处理为例， 要线速处理10G的网络需要的大约4个Xeon CPU的核，也就是说单是做网络数据包处理，就可以占去一个8核高端CPU一半的算力。D...。

未来展望：CXL、AI与存储的纠缠

让我们一起... SNIA SDC 2024: 存储网络行业协会开发者大会是一场非同寻常的活动！今年的议程安排十分紧凑， 包含了80多场技术讲座，能让人深入了解人工智能/机器学习、CXL、Computational Storage、数据基础设施、文件系统与协议等诸多领域的最新进展。我们的专家演讲者分享了对于塑造行业未来的前沿技术的宝贵见解。

虽然我去不了但我能感觉到那种躁动。CXL、计算型存储，这些新名词层出不穷。NVMeTCP 卸载实施和性能提升也是热门话题。在本次演讲中，我们将介绍NVMeTCP直接数据放置和CRC卸载设计以及支持它的驱动程序-硬件交互。我们将在各种比较和不同条件下展示卸载的性能优势。我们还将介绍我们面临的挑战以及我们如何解决这些挑战。Linux ULP和DDP文档也是必须要看的，虽然那些文档看起来就像天书一样，这事儿我得说道说道。。

优化DPU上的NVMe Over TCP卸载性能，不是一件容易的事。它需要你懂协议，懂硬件，懂驱动，还得有耐心。但是一旦你搞定了那种飞跃式的提升，那种CPU占用率下降的快感，真的是...太爽了。 原来如此。 虽然过程很痛苦，充满了噪音和调试的绝望，但这就是技术的魅力，对吧？希望这篇文章能给你一点点启发，哪怕只是让你觉得“原来大家都在受苦”，那我也心满意足了。加油吧，工程师们！