4. 存储网络加速需求分析

要理解 DPU 为什么值得为存储网络单独做加速，先要把“瓶颈到底在哪里”拆开看。存储网络加速不是把网卡换成更快的网卡，而是识别出一条 I/O 路径上哪些环节在消耗时延、哪些环节在限制吞吐，再判断哪些环节适合卸载到 DPU。本节围绕 NVMe over Fabrics（NVMe-oF）、分布式存储和超融合三类典型场景，分析它们的时延构成与吞吐约束。

一、先建立时延预算的参照系

讨论瓶颈前必须统一参照约定。本节所有时延均指端到端单次 I/O 时延，即从主机应用发起读/写请求，到收到完成响应为止，单位为微秒（μs）。吞吐指单节点可持续的有效数据带宽，单位为 GB/s。方向约定：主机侧为发起端（Initiator），存储侧为目标端（Target）。

一个典型的 NVMe-oF 读 I/O 路径可以拆成若干段：应用与文件系统/块层处理、主机协议栈（NVMe 命令封装）、传输层（RDMA 或 TCP）、网络交换、目标端接收与解析、后端介质访问、响应回传。在本地 NVMe SSD 上，一次 4KB 随机读的端到端时延通常在 80～120μs 量级；而一旦跨网络，同样的 I/O 往往上升到 200～400μs。多出来的部分，正是存储网络加速要压缩的对象。

二、NVMe over Fabrics：协议栈是主要时延来源

NVMe-oF 的核心价值是把本地 NVMe 的低时延语义延伸到网络上，支持 RDMA（RoCEv2、InfiniBand）和 TCP 两类传输。RDMA 路径通过内核旁路和零拷贝，把传输层时延压到几十微秒；TCP 路径则要经过完整内核协议栈，时延通常高出 50～150μs，且在高 PPS 下 CPU 占用急剧上升。

瓶颈的典型表现有三类。第一，小 I/O 高 IOPS 场景下 CPU 成为瓶颈：4KB 随机读达到 50 万 IOPS 时，仅软中断和协议处理就可能吃掉多个物理核，留给应用的算力被挤占。第二，队列深度与并发不足：NVMe 依赖多队列并行，若主机侧队列数或中断亲和性配置不当，单队列成为串行点。第三，目标端解析开销：目标端每收一个命令都要做协议解析、内存映射和完成队列写入，这部分在纯软件实现中难以随核数线性扩展。

判断是否已触及协议栈瓶颈，可以观察三个信号：CPU 的 softirq 或 ksoftirqd 占用是否随 IOPS 线性上升；单核 %sys 是否接近饱和；在 IOPS 提升时端到端时延是否出现非线性拐点。若三者同时出现，说明瓶颈在主机或目标端的协议处理，而非网络或介质。

三、分布式存储：网络往返与副本放大

分布式存储把数据切分并复制到多个节点，一次写请求往往触发多次网络往返。以三副本为例，客户端写入主副本后，主副本再同步转发到两个从副本，全部确认后才返回。这意味着一次逻辑写在实际链路上产生 3 次以上的数据传输和多次确认往返。

这里的吞吐瓶颈来自两个方向。其一是东西向流量放大：三副本使节点间流量达到客户端有效带宽的 2～3 倍，交换机背板和节点网卡先于客户端网卡饱和。其二是一致性协议开销：副本确认、元数据更新、心跳与租约维护都消耗 CPU 和网络，且随节点规模增长而增加。

时延方面，分布式存储的端到端时延近似等于“客户端到主副本往返 + 主副本到从副本往返 + 介质访问”。若跨机架或跨可用区，光传输和交换时延会显著抬升下限。因此分布式存储的优化重点通常不是单次 I/O 的极限时延，而是在保证副本一致性的前提下，降低单位有效带宽的 CPU 与网络开销。

四、超融合：计算与存储争抢同一资源

超融合（HCI）把计算、存储、网络收敛到同一批节点上，存储流量与业务流量共享同一张网卡和同一批 CPU 核。这带来一个结构性矛盾：存储副本同步产生的东西向流量会与业务南北向流量争抢带宽，存储协议处理会与虚拟机争抢 CPU 时间片。

超融合场景的瓶颈特征与纯分布式存储不同。它更常表现为尾时延恶化：平均时延看似正常，但 P99 时延因资源争抢而大幅抖动。原因是存储 I/O 的完成时间受同节点上其他负载影响，缺乏稳定的资源隔离。此外，重建（Rebalance）期间流量激增，会进一步挤压业务带宽。

因此超融合的加速需求集中在三点：把存储协议处理从业务 CPU 上剥离、为东西向存储流量提供可预期的带宽与优先级、降低副本同步路径上的处理时延。这正是 DPU 能够直接介入的位置——将 NVMe-oF 目标端、副本转发、校验与加密卸载到 DPU，使主机 CPU 专注于业务。

五、三类场景的瓶颈对照