NVMeoTCP 的落地挑战与解决方案

全文概览

随着云计算和分布式系统的普及，如何高效地访问远端存储，成为了一个亟待解决的问题。NVMe over TCP (NVMeoTCP) 作为一种通过标准以太网传输 NVMe 协议的技术，为解耦存储提供了可能，但其性能优化却面临诸多挑战。

您是否曾困惑于，为什么即使使用了高速网络和存储设备，数据传输依然存在瓶颈？为什么将存储卸载到 DPU 上，看似能减轻宿主机负担，却引入了新的复杂性？数据在网络、内核、用户空间和硬件之间来回“跳跃”，这些不必要的拷贝和处理开销，正是吞吐量和时延的“隐形杀手”。

本文将深入探讨在 DPU 环境下优化 NVMeoTCP 所面临的技术难题，包括恼人的折返缓冲、用户空间拷贝、协议处理开销以及安全性挑战。同时，我们将剖析业界为解决这些问题提出的多种技术方案，从传统的 TCP 卸载引擎到现代的零拷贝 Socket、ULP DDP、io_uring，乃至前沿的 TCP DEVICEMEM 技术。通过对比分析这些方法的优劣和适用场景，希望能为您揭示高性能网络存储优化的核心秘密，并展望未来的发展方向。

阅读收获

• 理解在 DPU 环境下优化 NVMeoTCP 的主要技术挑战。
• 掌握多种 TCP 优化技术（如零拷贝 Socket, io_uring, ULP DDP, TCP DEVICEMEM）的核心原理和优势。
• 识别不同优化方案在解决折返缓冲、用户空间拷贝、协议处理等问题上的能力差异。
• 了解高性能 NVMeoTCP 集成的未来发展趋势和关键方向。

DPU 卸载 NVMeoTCP 所面临的技术挑战

DPU 卸载 NVMeoTCP 所面临的技术挑战

尽管 DPU 在解耦存储中具有显著优势，但在将 NVMeoTCP 处理完全卸载到 DPU 时，仍然存在一些技术难题：

1. 折返缓冲 (Bounce Buffering):
   • 问题：数据需要在 DPU 内部和 DPU 与宿主机之间进行多次 DMA 操作（从网卡到 DPU 内存，再从 DPU 内存到宿主机内存）。
   • 影响：增加了 DPU 内存（DDR）的利用率，即使数据最终是发往宿主机的。还可能导致 DPU 内部不同工作负载之间的“吵闹邻居”问题。
2. 用户空间拷贝 (User Copy):
   • 问题：在 DPU 内部，数据可能需要在 DPU 内核空间和用户空间之间进行额外的拷贝（特别是如果 NVMeoTCP 发起端在用户空间实现）。
   • 影响：如果无法消除，会进一步增加 DPU 内存利用率和处理时延。
3. 协议数据单元 CRC 计算 (PDU CRC):
   • 问题：NVMe over TCP 协议数据单元包含数据摘要（校验）。
   • 影响：计算这些摘要会消耗 DPU 的 CPU 周期。
4. 乱序的协议数据单元 (Out of Order PDU):
   • 问题：虽然 TCP 协议保证了数据流的有序性，但在 TCP 流内部的 NVMe PDU 可能会以乱序到达。
   • 影响：在这种情况下，难以执行简单的直接缓冲区拷贝，可能需要额外的排序或缓冲机制，增加了处理复杂性。
5. 安全性处理 (Security):
   • 问题：实现传输中数据 (TLS) 或静态数据 (OPAL TCG SED) 的安全性是必要的。
   • 影响：将 TLS 等安全协议处理卸载到 DPU 上是复杂的，需要 DPU 具备相应的硬件加速或高性能处理能力。
6. 时延增加 (Latency):
   • 问题：数据需要在宿主机和 DPU 之间进行一次额外的“跳跃”或传输。
   • 影响：尽管 DPU 旨在降低宿主机 CPU 开销，但这额外的硬件层和传输路径本身会引入一定的时延增量，可能高于纯粹的本地访问。

这些问题表明，在 DPU 上实现高效的 NVMeoTCP 卸载需要精心设计硬件和软件，以最小化不必要的内存拷贝和处理开销，同时有效处理协议的复杂性和安全需求。克服这些挑战是实现 DPU 在存储卸载中全部潜力的关键。

下文，依次介绍上述技术问题的优化思路。

定制 TCP 协议栈 (TCP 卸载引擎 TOE)

定制 TCP 协议栈 (TCP 卸载引擎 TOE)

• 概念：
  • TCP 卸载引擎 (TOE) 是一种技术，旨在通过在网卡硬件中实现并运行一个定制的 TCP/IP 协议栈来处理网络传输，从而减轻宿主机 CPU 的 TCP/IP 处理负担。
  • 在 NVMe over TCP 的场景中，TOE NIC 会在硬件中运行 NVMe over TCP 发起端和 TCP/IP 协议栈。
• TOE 旨在解决的问题：
  • 消除用户空间拷贝 (Usercopy)： TOE NIC 可以直接将数据从网络传输到应用缓冲区，避免了数据在内核和用户空间之间的拷贝。
  • 消除折返缓冲 (Bounce Buffering)： TOE 可以直接将数据从网络传输到宿主机内存（或从宿主机内存传输到网络），避免了数据在宿主机内存和网卡内部缓冲之间的多次拷贝。
  • 目标是降低时延并节省宿主机 CPU 资源。
• 工作原理示意 (参考图示):
  • 应用直接与 TOE NIC 通信。
  • TOE NIC 内部运行定制的 TCP/IP 协议栈和 NVMe over TCP 发起端。
  • TOE NIC 通过 DMA 将数据直接传输到应用的缓冲区或从应用缓冲区读取数据。
  • TOE NIC 通过其以太网接口连接到远程存储。
• 局限性与普及受阻的原因：
  • 安全性问题： 在硬件中实现完整的 TCP 协议栈并确保其安全性是一个挑战。
  • 维护问题： 定制硬件协议栈的维护比软件复杂。
  • 更新周期慢： 相较于软件协议栈，硬件协议栈的更新和迭代周期很长。
  • 添加新功能延迟： 在硬件中实现新的 TCP 特性或功能需要重新设计或升级硬件，速度很慢，无法跟上软件协议栈的快速发展。
• 安全性处理：
  • 理论上，安全性（如 TLS 加密）可以在 TOE NIC 硬件中处理，但这增加了实现的复杂性。

零拷贝 Socket 机制

零拷贝 Socket 机制

• 核心概念：
  • 零拷贝 Socket 是一种网络数据传输优化技术，旨在通过避免数据在内核空间和用户空间之间的不必要拷贝，减少 CPU 开销和时延。
• 实现方式 (以 TCP 为例):
  • 发送： 使用 MSG_ZEROCOPY Socket 选项。应用可以将数据直接放入用户空间的缓冲区，内核通过 DMA 将数据从用户空间缓冲区发送到网卡。
  • 接收： 使用 TCP_ZEROCOPY_RECIEVE Socket 选项。内核将网卡接收到的数据所在的内存页直接映射到用户空间的缓冲区，应用可以直接访问这些映射的内存，无需额外拷贝。图中 Socket 旁边的 mmap user buffers 也体现了这一点。
• 带来的好处：
  • 消除拷贝： 最主要的优势在于消除了数据在内核缓冲区和用户空间应用缓冲区之间的拷贝操作，节省了 CPU 周期和内存带宽。
• 局限性、要求和未解决的问题：
  • 页面对齐要求： 零拷贝通常只适用于数据有效载荷是页面对齐的情况。
  • PDU CRC 处理： 零拷贝 Socket 本身不处理 NVMe over TCP PDU 的 CRC 校验，这需要由用户空间的应用（如 NVMeoTCP 发起端）来完成。
  • 网卡需求： 如果网卡不支持某些高级功能（如 HDS），可能需要网卡支持分散接收（scatter receive）。
  • 映射/解映射开销： 每次接收可能需要进行内存页的映射和解映射操作，这会带来一定的管理开销。
  • 未避免折返缓冲： 零拷贝 Socket 主要解决了内核与用户空间之间的拷贝，但并未完全避免网卡内部缓冲区与宿主机内存之间的折返缓冲问题（尤其是在发送路径或没有 HDS 的情况下）。
  • 安全性处理： TLS 等安全性处理通常需要在内核空间进行，零拷贝 Socket 本身不负责处理安全性。
• 工作原理示意：
  • 应用通过 Socket（映射了用户空间缓冲区）与内核的 TCP/IP 协议栈交互。
  • 数据绕过传统的内核缓冲区拷贝，通过 DMA 或直接映射的方式在应用缓冲区和网卡之间传输。
  • 图中箭头跳过了 Kernel Buffers 直接指向 Socket (mmap user buffers) 和 NIC Driver，体现了零拷贝的核心思想。

内核态 ULP DDP 卸载

内核态 ULP DDP 卸载

• 概念：
  • 这是一种在内核层面实现的 NVMe over TCP 卸载机制，利用 User-Level Protocol Data Placement (ULP DDP) 原理，旨在实现高性能的数据路径。
  • 它与零拷贝 Socket 有些相似，都追求减少数据拷贝，但 ULP DDP 更侧重于将数据直接放置到目标位置。
• 工作原理与流程 (参考图示):
  • 应用（如 NVMe over TCP Initiator）通过 Socket 与内核的 TCP/IP 协议栈交互。
  • 数据（特别是有效载荷 Payload）被组织成 BIO PAGES，这些页面可以被直接（通过 HDS）从网卡接收，跳过传统的内核缓冲区拷贝，直接放置到应用预先准备好的内存区域（App Memory Buffers）。
  • HDS 是实现这一机制的关键，它能够根据网络协议头部（TCP 和 PDU 头部，可能从接收环获取）和应用指示，将 Payload 从网卡直接传输到用户空间缓冲区。
  • 图中 If (src == dst) skip memcpy 暗示在某些优化路径下可以跳过内存拷贝。
• 带来的好处：
  • 消除用户空间拷贝 (Eliminates Usercopy): 数据从网卡直接到达应用缓冲区，避免了内核与用户空间之间的拷贝。
  • 卸载 PDU CRC 处理 (PDU CRC processing is offloaded): 将 PDU CRC 的计算或校验任务卸载到硬件（网卡）或 DPU 上进行处理。
  • 卸载安全性处理 (Security can be offloaded): 安全协议（如 TLS）的处理也可以被卸载。
  • 存储协议跳过拷贝 (Storage protocol skips copy): 这指的是在理想情况下，从存储协议层面上看，数据传输过程中不需要额外的软件拷贝。
• 存在的挑战与未解决的问题：
  • 乱序的协议数据单元 (Out of order PDU is a concern): 尽管 TCP 保证流的有序性，但 ULP DDP 处理 PDU 时仍需考虑 PDU 可能乱序到达的情况，这会增加处理的复杂性。
  • 折返缓冲未避免 (Bounce buffering is not avoided): 这种机制主要解决了用户空间拷贝，但并未解决网卡内部缓冲区与宿主机内存之间的折返缓冲问题。
  • PDU 可能被重新排序 (PDUs can get reordered): 需要处理 PDU 在网络或处理过程中可能发生的乱序。
• 与零拷贝 Socket 的区别：
  • ULP DDP 更像是一种在内核层面实现的更高级别的卸载机制，它不仅涉及数据拷贝的避免，还可能包含协议处理（如 CRC）的卸载，并且与存储协议栈结合更紧密（利用 BIO PAGES 等内核结构）。零拷贝 Socket 更多是操作系统提供的通用网络 Socket 选项。

基于 IO URING 的零拷贝机制

基于 IO URING 的零拷贝机制

• 核心概念：
  • 利用 Linux 内核的 io_uring 接口来实现高性能的网络 I/O 零拷贝，特别适用于需要直接访问用户空间缓冲区的场景（如 NVMe over TCP）。
  • io_uring 的核心在于用户空间和内核共享提交和完成队列，减少了系统调用开销。
• 工作原理与机制：
  • 共享环： 用户空间和内核通过共享内存中的环形缓冲区进行通信（提交队列 SQ、完成队列 CQ、填充环 Refill）。
  • 异步 I/O： 应用将 I/O 请求放入 SQ，内核从 SQ 中获取并执行。内核完成后将结果放入 CQ，应用从 CQ 中获取完成通知。
  • 内存注册与零拷贝： 用户空间的应用需要使用 io_uring 注册其使用的内存缓冲区（App Memory Buffers）。内核知道这些缓冲区的物理地址和权限，从而可以指示硬件（网卡）将接收到的数据直接 DMA 到这些用户空间缓冲区中，或直接从这些缓冲区读取数据进行发送，消除了用户空间和内核缓冲区之间的拷贝 (Eliminates usercopy)。
  • 硬件协助： 依赖网卡硬件的 HDS (Header Data Split) 和 RSS (Receive Side Scaling) 流定向等功能，帮助将数据头部和有效载荷分发到正确的缓冲区。
  • 填充接收环： 需要使用用户空间注册的缓冲区来填充网卡硬件的接收有效载荷环，以便网卡可以直接将数据放入这些缓冲区。
• 带来的好处：
  • 消除用户空间拷贝 (Eliminates usercopy): 这是 io_uring 零拷贝最直接的性能优势，减少了 CPU 负载和数据传输时延。
  • 减少系统调用： 通过共享环进行异步 I/O 提交和完成，减少了频繁的系统调用开销。
• 要求和限制：
  • 应用需要修改： 应用程序需要修改其 I/O 模型，从传统的阻塞/非阻塞系统调用切换到 io_uring 接口。
  • 需要用户空间发起端： 对于像 NVMe over TCP 这样的协议，需要一个用户空间的发起端（如 SPDK）来利用 io_uring 进行高性能 I/O 处理。
  • 未避免折返缓冲 (Bounce buffering is not avoided):io_uring 零拷贝主要解决了用户空间与内核之间的拷贝，但数据在网卡内部缓冲区与宿主机内存之间仍然可能存在折返缓冲。
  • 安全性由内核处理 (Security has to be handled by kernel): TLS 等网络安全性处理通常需要在内核中进行，io_uring 本身不负责安全性。
  • 内存管理开销： 需要进行内存注册和管理，可能涉及页面池 (Page Pools)。
• 图示关键点：
  • 展示了用户空间的应用如何通过 SQ/CQ 环与内核的 io_uring 接口交互。
  • 应用内存缓冲区 (App Memory Buffers) 通过缓冲区注册 (Buffer registration) 机制被内核知晓。
  • 数据流跳过了传统的内核缓冲区（图中未明确画出，但通过 Socket -> TCP/IP Stack -> NIC Driver -> HW 的路径以及与用户空间缓冲区的连接体现）。
  • 强调了网卡硬件 (HW) 的 HDS/RSS 流定向和 Page Pools 在零拷贝数据放置中的作用。

TCP DEVICEMEM - 直接数据放置到设备内存

TCP DEVICEMEM - 直接数据放置到设备内存

• 核心概念：
  • TCP DEVICEMEM 是一种旨在实现 TCP 有效载荷的直接数据放置 (Direct Data Placement) 的技术，特别是将其直接传输到设备内存（图中以 GPU 内存为例），而无需经过宿主机内存或用户空间。
• 实现机制与关键技术：
  • HDS (Header Data Split): 需要网卡支持头部数据分离，以便将 TCP/IP 头部与有效载荷分开处理。
  • 流定向 (Flow Steering): 需要网卡支持流定向功能，将特定的 TCP 流量引导到为 TCP DEVICEMEM 配置的接收队列。
  • 点对点 DMA (P2P DMA): 利用支持 P2P DMA 的硬件能力，允许网卡 (NIC) 直接将数据传输到 GPU 内存或其他支持 P2P 的设备内存，而无需通过宿主机 CPU 或内存作为中转。
  • Linux DMABUF 基础设施： 利用 Linux 内核提供的 DMABUF 机制，实现在不同设备驱动程序（如网卡驱动和 GPU 驱动）之间安全高效地共享缓冲区。DMABUF 提供了跨设备共享 DMA 缓冲区的标准方法。
  • 网卡硬件需求：
  • 缓冲区管理： 使用 Netlink 消息等机制将基于 DMABUF 创建的缓冲区池中的缓冲区填充到网卡的接收队列中。
• 带来的好处：
  • 直接放置： 数据直接从网卡到达目标设备内存（如 GPU 内存），避免了数据在网络堆栈和应用内存之间的多余拷贝。
  • 避免用户空间映射/解映射开销： 与零拷贝 Socket 将接收缓冲区映射到用户空间不同，TCP DEVICEMEM 旨在将数据直接放置到设备内存，避免了相关的映射/解映射管理开销。
• 当前的局限性：
  • 发送功能尚未支持 (TX is not yet supported): 目前该技术主要关注数据接收路径的优化。
  • 尚未合并到 Linux 内核主线 (Not yet upstreamed): 这意味着它目前可能是一个实验性或特定厂商的实现，尚未成为标准的 Linux 内核特性。
• 工作原理示意：
  • 网卡 (NIC) 接收到数据后，通过 HDS 分离头部和有效载荷。
  • 利用 DMABUF 和 P2P DMA，有效载荷直接从网卡传输到 GPU 内存。
  • TCP/IP 头部可能仍然由宿主机内核的 TCP 协议栈处理。
  • 应用通过 GPU 驱动或其他机制访问 GPU 内存中的数据。

将 TCP DEVICEMEM（利用 UDMABUF）应用于 NVMe over TCP

将 TCP DEVICEMEM（利用 UDMABUF）应用于 NVMe over TCP

• 核心概念：
  • 探讨如何将 TCP DEVICEMEM 的思想应用于 NVMe over TCP 场景，特别是利用 udmabuf 机制来实现用户空间应用和网卡之间的高效数据传输。
• UDMABUF 的作用：
  • udmabuf 是一个 Linux 内核机制，允许在内核空间分配连续的内存块，并将这些内存块作为 DMA 缓冲区暴露给用户空间应用。
  • 这样，用户空间应用（如 NVMe over TCP Initiator）就可以直接访问这些可供 DMA 使用的缓冲区。
• 工作流程与交互：
  • 用户空间的应用（NVMe over TCP Initiator）通过 udmabuf 机制获取 DMA 缓冲区（Memory Buffers）。
  • 应用通过 Netlink 消息将这些缓冲区的信息传递给网卡驱动程序，告诉网卡将接收到的数据放到这些缓冲区中。
  • 网卡驱动和硬件根据这些信息，通过 DMA 将接收到的数据有效载荷直接写入用户空间应用通过 udmabuf 获取的缓冲区中。
• 带来的好处：
  • 消除用户空间拷贝 (Usercopy is eliminated): 数据直接从网卡 DMA 到用户空间应用可访问的缓冲区，避免了数据在内核和用户空间之间的拷贝。
• 要求和限制：
  • 网卡硬件要求： 需要网卡支持流定向 (Flow Steering) 和 HDS (Header Data Split) 功能，以便将数据头部和有效载荷正确地分发到不同的目标。
  • DMA 折返缓冲未避免 (DMA bounce buffering is not avoided): 尽管消除了用户空间拷贝，但数据在网卡内部缓冲区和系统内存（udmabuf 分配的缓冲区）之间仍然可能存在 DMA 折返缓冲。
  • 安全性无法卸载 (Security cannot be offloaded): 安全性相关的处理（如 TLS 加密/解密）无法通过这种机制卸载到硬件。
• 图示关键点：
  • 展示了用户空间的应用与 udmabuf 交互，获取 Memory Buffers。
  • 通过 Netlink 消息将缓冲区信息传递给 NIC Driver。
  • 数据流显示 Payload 直接从 NIC 硬件通过 DMA 到达 Memory Buffers (UDMABUF)，绕过了传统的内核缓冲区拷贝。
  • 突出了网卡硬件对 Flow Steering 和 HDS 的依赖。

不同 TCP 优化方法的特性对比总结

不同 TCP 优化方法的特性对比总结

下表总结了前述几种 TCP 优化方法在解决特定问题上的能力：

总体观察：

• 消除用户空间拷贝是大多数现代 TCP 优化方法都能实现的目标。
• 折返缓冲和乱序 PDU 是更难解决的问题，只有理想化的定制 TOE 声称可以解决。
• PDU CRC 和 TLS 卸载是部分更高级的卸载机制（如定制 TOE 和 ULP DDP）才能实现的功能。
• TCG OPAL SED 安全卸载似乎更多是与存储设备本身或存储栈集成的问题，而非纯粹的网络传输优化问题，因此多种方法都能支持。

表格为理解不同 TCP 优化技术的能力边界提供了一个清晰的概览。

TCP 优化和 NVMe over TCP 集成的未来发展方向

TCP 优化和 NVMe over TCP 集成的未来发展方向

• 解决 DMA 折返缓冲问题：
  • 研究和寻找不依赖于复杂的定制 TCP 协议栈就能消除或减轻 DMA 折返缓冲的技术方案。这是提高数据传输效率的关键瓶颈之一。
• 结合 TLS 卸载与折返缓冲避免：
  • 在致力于避免 DMA 折返缓冲的同时，探索将 TLS 加密/解密处理卸载到硬件或 DPU 的方法。这将有助于在保证数据安全性的前提下提升性能。
• 在 SPDK 中集成 udmabuf 和 TCP Devicemem：
  • 计划扩展用户空间的 NVMe 性能开发工具包 (SPDK)，使其能够利用 udmabuf 机制分配 DMA 缓冲区，并结合 TCP Devicemem 的思想实现更高效的数据路径，绕过用户空间拷贝。
• 在内核中集成 TCP Devicemem：
  • 计划扩展 Linux 内核中的 NVMe over TCP 发起端，使其能够利用 TCP Devicemem 技术，实现更直接的数据放置，优化内核态的数据传输效率。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. 在实际应用中，如何权衡不同 NVMeoTCP 优化方案的实现复杂度、硬件依赖性与性能提升效果？
2. 随着计算和存储架构的不断演进（如 CXL 的发展），未来 NVMeoTCP 的优化方向是否会发生根本性变化？
3. 除了本文讨论的技术，还有哪些新兴技术或方法可能进一步提升 NVMeoTCP 在解耦存储场景下的性能和效率？

#NVMe协议 #高性能存储

原文标题：Optimizing NVMe Over TCP for Disaggregated Storage on DPUs

Notice：Human's prompt, Datasets by Gemini-2.5-flash-thinking

---【本文完】---