2. DPU硬件架构与网络数据路径

DPU（Data Processing Unit）不是一块“更快的网卡”，而是一台嵌入在PCIe插槽里的独立计算机。理解它的关键，是把它拆成三个平面来看：计算平面（多核Arm CPU集群）、网络平面（高速以太网MAC/PCS与包处理流水线）、存储与加速平面（DMA引擎、加密/压缩/正则等硬件加速器）。三者通过片上互联（NoC或交换矩阵）连接，对外则通过PCIe Gen4/Gen5 x16主机接口与CPU/GPU通信，通过以太网接口与外部网络通信。

一、DPU的组成与三类引擎

以典型数据中心DPU（如NVIDIA BlueField-2/3、AMD Pensando、Intel IPU）为例，其内部可归纳为：

• 计算引擎：8～16个Arm Cortex-A72/A78核心，运行Linux与DPDK/OVS，承担控制面与部分数据面卸载逻辑；
• 网络引擎：可编程包处理流水线（P4/可编程parser-match-action），支持SR-IOV、VirtIO、RDMA、RoCEv2、IPsec/MACsec加解密；
• 存储/加速引擎：NVMe-oF、压缩解压、正则匹配、SHA/AES引擎，用于卸载主机CPU的存储与安全负载。

这三类引擎共享片上DDR（通常8～32GB），并通过PCIe Switch或直接Root Complex与主机CPU、GPU互联。DPU的“独立性”体现在：即使主机CPU宕机，DPU仍可维持网络与存储服务，这正是云原生基础设施卸载的物理基础。

二、PCIe与网络接口的角色分工

DPU上有两个关键接口方向：PCIe侧面向主机，呈现为多个PF/VF（物理功能/虚拟功能），主机通过SR-IOV把VF直通给虚拟机；以太网侧面向外部网络，通常为2×25G/100G/200G端口。数据包从网口进入后，先经过MAC/PCS与可编程流水线，再决定是“上送DPU的Arm核处理”还是“直接DMA到主机内存中的VF队列”。

三、数据包处理流水线

DPU内部的数据包处理可抽象为五级流水线：解析（Parse）→ 分类（Classify）→ 动作（Action）→ 队列（Queue）→ 传输（DMA/Transmit）。解析级提取以太网、IP、TCP/UDP、VXLAN/Geneve等头部字段；分类级用TCAM/哈希表匹配五元组或隧道ID；动作级执行转发、封装、丢弃、镜像、计数；队列级按VF或QoS分配；传输级通过DMA写入主机内存或从网口发出。

四、与CPU/GPU的协同关系

在传统服务器中，网络数据面由CPU承担：每个包都要经过内核协议栈、中断、上下文切换，10Gbps以上时CPU开销急剧上升。DPU的引入改变了这一分工：CPU只处理控制面（如OVS流表下发、Kubernetes网络策略），DPU处理数据面（包转发、隧道封装、加解密）。以OVS卸载为例，主机上的ovs-vswitchd通过DPDK与DPU的VF通信，把流表下发给DPU硬件；后续同流数据包直接在DPU流水线内完成匹配与转发，不再经过主机CPU。

与GPU的协同则体现在AI训练场景：GPU需要从远端存储或另一节点读取训练数据。若走“网卡→CPU内存→GPU显存”的路径，会消耗大量CPU周期与PCIe带宽。DPU支持GPUDirect RDMA，允许网口收到的数据经DPU DMA引擎直接写入GPU显存，绕过主机内存。此时DPU扮演的是“GPU的网络前端”，把存储访问（NVMe-oF）与集合通信（NCCL/RoCE）都卸载到硬件。

五、一个可观察的卸载判断示例

假设在主机上执行以下命令查看VF与流表状态：

# 查看 DPU 呈现的 VF
lspci -d 15b3: | grep -i bluefield
# 查看 OVS 卸载流表
ovs-appctl dpctl/dump-flows -m type=offloaded
# 观察 DPU 侧包计数
cat /sys/class/net/enp3s0f0/statistics/rx_packets

若 dump-flows 中某条流的 offloaded:yes 且 packets 持续增长，而主机CPU的软中断（/proc/softirqs 中 NET_RX）几乎不增长，即可判断该流已成功卸载到DPU快路径。反之，若流表显示 offloaded:no，说明包仍走Arm核慢路径，需要检查流表是否命中、VF是否绑定正确、隧道类型是否被硬件支持。

总结来看，DPU的硬件架构本质是把“服务器里最耗CPU的网络与存储数据面”下沉到一块带独立算力的PCIe设备中。理解计算/网络/存储三类引擎的分工、PCIe与以太网两个接口的方向、五级流水线的处理顺序，以及它与CPU/GPU的协同边界，是后续学习OVS卸载配置与性能调优的基础。