1. DPU与云原生网络加速导论

在传统数据中心里，服务器网卡只负责把数据帧搬进搬出内存，协议栈、安全策略、存储访问、虚拟交换全部由主机 CPU 承担。当业务从虚拟机迁移到 Kubernetes 容器之后，Pod 数量从几十个膨胀到上千个，每个 Pod 都带独立的网络命名空间、veth 设备、iptables/ipvs 规则和 TLS 连接，主机 CPU 被大量消耗在“替别人搬数据”上。DPU（Data Processing Unit）正是为改变这一分工而出现的专用处理器：它把网络、存储、安全、虚拟化这些基础设施负载从主机 CPU 卸载到独立的片上系统，让通用 CPU 专注运行业务容器。

DPU 的体系结构定位

从系统层级看，DPU 位于服务器 PCIe 总线上，与 CPU、GPU 并列成为“第三颗主芯片”。它内部通常包含三类资源：一是可编程的数据平面，由多核 ARM 处理器、硬件加速引擎（加解密、正则匹配、压缩、DMA）和高速网络接口组成；二是控制平面，运行轻量 Linux 与容器化网络组件；三是与主机协同的 PCIe 端点，通过 SR-IOV、VirtIO、RDMA 等机制向主机暴露虚拟功能（VF）。理解 DPU 的关键在于：它不是一块“更快的网卡”，而是一台“插在 PCIe 上的小型服务器”，拥有自己的操作系统、内存和网络栈。

在云原生场景中，DPU 的定位可以概括为三层：最底层是物理网络接入，负责 25/100/200 GbE 线速收发；中间层是基础设施卸载，承载 OVS 虚拟交换、VXLAN/Geneve 隧道封装、NAT、ACL、IPsec/TLS 加解密；最上层是面向 Kubernetes 的服务平面，提供 CNI 插件、Service 负载均衡、网络策略执行和可观测性采集。主机侧看到的只是若干 VF 和标准网络接口，真正的转发与策略逻辑已经下沉到 DPU。

云原生网络性能瓶颈从哪里来

要理解卸载的价值，先要看清瓶颈。以一个典型的三层微服务调用为例：客户端 Pod 发出请求，经过 veth 对进入主机网络命名空间，被 iptables 或 ipvs 做 DNAT，再经 OVS 流表匹配、VXLAN 封装，最后通过物理网卡发出。返回路径还要反向执行一遍。这条路径上，每个数据包都要经历多次内存拷贝、上下文切换和规则匹配。在 10 GbE 线速、64 字节小包条件下，包速率可达约 14.88 Mpps，主机 CPU 往往需要 8 到 16 个核才能勉强处理，留给业务的算力被严重挤压。

更隐蔽的瓶颈来自“规则规模”。Kubernetes 集群中 Service 数量达到数千时，iptables 规则链长度线性增长，单包匹配耗时随之上升；TLS 握手和对称加解密在软件栈中消耗大量指令周期；网络策略、可观测性探针、服务网格 Sidecar 又各自增加一跳处理。这些开销的共同特征是：它们与业务逻辑无关，却必须逐包执行。DPU 的卸载思路，就是把这些“逐包重复劳动”从主机 CPU 迁移到专用硬件流水线。

卸载与加速的基本原理

卸载并不是简单地把代码搬到另一颗芯片上，而是要在保持语义一致的前提下改变执行位置。常见做法有三类。第一类是数据面卸载：把 OVS 流表、VXLAN 封装、NAT、ACL 编译成 DPU 上的硬件或可编程流水线，主机侧只保留控制通道。第二类是协议卸载：IPsec、TLS、RoCEv2 的加解密与可靠传输由 DPU 加速引擎完成，主机看到的是明文或已完成握手的连接。第三类是设备卸载：NVMe-oF、virtio-blk 等存储访问由 DPU 直接代理，主机通过标准块设备接口读写。

判断卸载是否成功，不能只看吞吐数字，还要看语义是否等价。例如，把 kube-proxy 的 Service 负载均衡卸载到 DPU 后，必须保证 ClusterIP、NodePort、会话保持、健康检查等行为与原来一致；把网络策略卸载后，必须保证拒绝/放行的判定结果与主机侧一致。因此工程上通常采用“先旁路观测、再灰度卸载、最后全量切换”的路径，并用丢包率、P99 时延、CPU 占用、连接建立成功率等指标交叉验证。

课程工程目标与实验环境

本课程的目标不是泛泛介绍 DPU 概念，而是围绕“把云原生网络能力真正落到 DPU 上”这条主线，完成从环境搭建、CNI 对接、Service 卸载、网络策略下发、TLS 加速到性能验证的完整工程闭环。学完后，你应当能够独立判断一个云原生网络功能是否适合卸载、如何设计卸载边界、如何验证卸载前后语义一致，并能读懂 DPU 侧的流表、计数器与主机侧指标之间的对应关系。

实验环境采用一台具备 SR-IOV 能力的 DPU 加速服务器作为主机节点，DPU 以 PCIe 卡形式安装，主机侧启用 IOMMU 并创建若干 VF。软件栈包括：主机侧 Kubernetes 集群（kubelet、containerd、CNI 插件）、DPU 侧 ARM Linux 与容器化网络组件、以及用于下发流表和策略的控制面工具。网络拓扑上，主机业务口与 DPU 管理口分离，业务流量经 VF 进入 DPU 数据平面，管理流量走独立千兆口，避免实验操作干扰被测路径。

# 主机侧查看 DPU 与 VF 示例（示例输出，非实测）
$ lspci -d ::0200
03:00.0 Ethernet controller: DPU Vendor Device (rev 01)
03:00.1 Ethernet controller: DPU Vendor Device (rev 01)   # VF0
03:00.2 Ethernet controller: DPU Vendor Device (rev 01)   # VF1

$ ip link show
ens1f0np0: <BROADCAST,MULTICAST,UP> mtu 1500
ens1f0v0: <BROADCAST,MULTICAST,UP> mtu 1500   # 分配给 Pod 的 VF

实验中的关键观察点包括：主机侧 top 中 si（软中断）占比、mpstat -P ALL 各核利用率、DPU 侧流表命中计数、以及 iperf3 或 wrk 测得的吞吐与 P99 时延。判断卸载是否生效，可以对比同一压测下主机 CPU 占用是否显著下降、DPU 计数器是否随流量增长、以及业务请求的成功率是否保持稳定。若主机 CPU 下降但时延反而上升，往往说明卸载路径引入了额外跳数或队列配置不当，需要回到流表和队列映射上排查。