3. DPU 软件栈与数据面路径

在 Marvell OCTEON 10 DPU 上做性能基准，第一步不是急着跑 iperf3 或 pktgen，而是先厘清“报文从网口进来，到被应用处理，中间经过了哪些软件层”。因为同一块 DPU，走内核协议栈、走 DPDK 用户态轮询、走 OVS 硬件卸载，其吞吐和时延可能相差数倍。基准测试的切入点，本质上取决于你要评估的是哪一段数据面路径。

三种部署形态的定位

Marvell DPU 的软件栈可以按“控制面—数据面—加速面”三层理解。控制面由 Linux 内核与 DOCA 服务构成，负责设备管理、驱动加载、策略下发；数据面则由 DPDK、OVS-DPDK 或 DOCA Flow 承担实际报文转发；加速面是 OCTEON 10 内置的硬件卸载引擎，包括 packet processor、crypto 引擎和 regex 引擎。

DPDK 形态是最贴近硬件的用户态路径。在 Marvell DPU 上，DPDK 通过 octeontx2 PMD（Poll Mode Driver）直接接管网口队列，绕过内核网络栈。应用通过 rte_eth_rx_burst() 批量收包，在用户态完成解析、查表、转发。这条路径的基准测试关注的是 PMD 的 burst 性能、mbuf 池大小、NUMA 亲和性以及队列深度。

OVS-DPDK 形态是在 DPDK 之上叠加 Open vSwitch 的流表转发。它适合需要 OpenFlow 策略、VLAN 隔离、隧道封装的场景。在 Marvell DPU 上，OVS 的 netdev 数据面绑定到 DPDK PMD，流表匹配和动作执行在用户态完成；而 dpdk 数据面则进一步利用 OCTEON 10 的 flow offload，把已命中的流表项下沉到硬件。基准测试需要区分“慢路径首包”和“快路径命中”两种状态。

DOCA 形态是 Marvell 主推的编程框架，它在 DPDK 和硬件卸载之上提供更高层抽象。DOCA Flow 用管道（pipe）和条目（entry）描述报文处理逻辑，DOCA Eth 管理网口，DOCA DMA 处理主机与 DPU 间的数据搬运。DOCA 的价值在于把“写 DPDK 代码”变成“配置管道”，但代价是灵活性下降。基准测试要关注管道编译时间、条目下发速率和硬件表项容量。

报文处理流水线

以一块双口 100G Marvell DPU 为例，一个典型的入向报文路径如下：报文从 PHY 进入 MAC，由 octeontx2 的 NIX（Network Interface Controller）单元写入 DDR 中的 packet buffer；DPDK PMD 从 RX 队列批量取走 mbuf，交给应用或 OVS 处理；若命中硬件流表，则 NIX 直接执行修改和转发动作，不经过 CPU。这条流水线的关键观测点是：NIX 队列的填充/排空速率、mbuf 缓存命中率、CPU 各核的 rx_burst 与 tx_burst 计数，以及硬件流表的 hit/miss 比例。

下面这张图展示了三种部署形态在 Marvell DPU 上的分层关系与数据面路径，同时标出了基准测试的四个切入点。

基准测试的四个切入点

结合上面的分层图，实际基准测试可以从四个位置切入，每个位置观测的指标不同。

切入点一：DPDK PMD 裸吞吐。这是最底层的基准。用 testpmd 绑定两个网口，设置 --rxq=8 --txq=8，mbuf 池设为 8192，开启 --burst=32。在 100G 线速下，观察 rx_burst 返回的包数是否稳定在 32，以及 tx_burst 是否出现丢包。若 rx_burst 频繁返回小于 32，说明 NIX 队列深度不足或 CPU 核被抢占。这个切入点的典型目标是单核 20～30 Mpps 的纯转发能力，具体数值取决于包长和 CPU 频率。

切入点二：OVS-DPDK 流表性能。在 OVS 中配置 dpdk 数据面，添加一条 in_port=1,dl_type=0x0800,nw_dst=10.0.0.1 的流表，动作是 output:2。用 ovs-appctl dpif-netdev/pmd-stats-show 观察 packets per upcall 和 upcalls 计数。首包会触发 upcall 到 ovs-vswitchd，后续包在用户态命中。基准测试要分别测量“首包时延”和“稳态吞吐”，并观察 pmd-stats 中 datapath 与 upcall 的比例。

切入点三：DOCA Flow 管道下发。DOCA Flow 的基准不是转发吞吐，而是管道编译和条目下发速率。用 doca_flow_pipe_create() 创建一条匹配五元组的 pipe，再用 doca_flow_pipe_add_entry() 批量下发 1000 条 entry，记录从调用到返回的耗时。若单条 entry 下发超过 100 微秒，说明硬件表项资源紧张或驱动存在锁竞争。这个切入点的目标是每秒下发 1 万条以上 entry。

切入点四：硬件卸载命中率。当 OVS 或 DOCA 把流表下沉到 NIX 后，用 ethtool -S 或 Marvell 提供的 octeontx2 调试接口读取 flow_hit 和 flow_miss 计数。命中率低于 90% 时，大量报文仍走 CPU 慢路径，整体吞吐会明显下降。基准测试要构造足够多的流（例如 10 万条五元组），观察硬件表项容量和替换策略对命中率的影响。

如何选择切入点

如果你的目标是评估 DPU 的极限转发能力，从切入点一开始，逐步向上叠加 OVS 和 DOCA，观察每一层带来的性能损耗。如果目标是验证某个业务场景（例如 IPsec 网关），则直接从切入点四开始，先确认硬件卸载是否生效，再回退到切入点二分析慢路径开销。无论从哪个切入点开始，都要固定包长、流数量、CPU 亲和性和 mbuf 池大小这四个变量，否则不同轮次的测试结果不可比。

最后需要强调：DOCA、DPDK、OVS 三者不是互斥的，而是可以组合的。在 Marvell DPU 上，常见做法是用 DOCA Flow 管理硬件流表，用 DPDK PMD 处理未命中的报文，用 OVS 提供控制面策略。基准测试的价值，正是把这条组合路径中每一段的性能边界量化出来，为容量规划提供依据。