DPDK 为什么“零拷贝”后 CPU 反而更高了？—— 一次 mbuf 生命周期失控引发的性能灾难

一、问题背景：一次“看起来很正确”的优化

几年前，我在做一个基于 DPDK 的用户态网关。

系统核心路径并不复杂：

RX ↓ Parser ↓ ACL ↓ NAT ↓ TX

最开始，系统采用的是：

memcpy()

方式处理部分报文。

例如：

• VLAN 修改
• GTP-U decap
• Header rewrite
• NAT 改写

由于涉及：

packet rebuild

因此部分场景需要重新组织报文。

这时候团队里有人提出：

为什么不做零拷贝？

理由看起来非常合理：

• memcpy 很耗 CPU
• 零拷贝更先进
• Linux Kernel 也在零拷贝
• DPDK 本来就是高性能框架

于是系统开始大量引入：

• rte_pktmbuf_clone()
• indirect mbuf
• external buffer
• scatter/gather
• chained mbuf

大家觉得：

性能一定会提升

结果：灾难开始了。

二、系统出现了“越零拷贝越慢”

最开始，只是：

CPU utilization 上升

后来，问题越来越严重：

• PPS 下降
• latency 抖动
• LLC miss 暴涨
• TX queue recycle 变慢
• 某些 core 时不时 100%

更奇怪的是：

memcpy 已经明显减少

按理说：CPU 应该下降才对。

但实际上：系统反而更慢了。

三、为什么“少 memcpy”不一定意味着更快？

很多人理解性能优化：

会本能认为：

memcpy = 性能杀手

但实际上，现代 CPU真正怕的并不是：

计算

而是：

随机内存访问

也就是说：一次 cache miss，可能比：

几十字节 memcpy

代价更高。

这是现代 CPU 微架构一个非常重要的事实。

四、现代 CPU：真正昂贵的是 Memory Stall

后来我们使用：

perf stat

分析系统。

发现：CPU cycles 大量消耗在：

stalled-cycles-backend

也就是说：CPU 并不是在执行 memcpy。

而是在：

等待内存

这时候，问题方向彻底变了。

五、DPDK mbuf 真正的本质

很多人把 mbuf 理解成：

一个 packet buffer

其实不准确。

真正的 mbuf 本质是：

packet metadata + data pointer

结构类似：

struct rte_mbuf { void *buf_addr; uint16_t data_off; uint16_t data_len; uint32_t pkt_len; uint16_t refcnt; };

注意：

真正的数据通常并不在 mbuf 本身。

而在：

buf_addr 指向的 data buffer

因此。

所谓：

零拷贝

本质上是：

共享 data buffer

六、clone 真正做了什么？

例如：

rte_pktmbuf_clone()

很多人以为：clone 很轻量。

实际上，它做的是：

多个 mbuf 共享同一块 data buffer

于是：

原来的：

独占 ownership

变成：

共享 ownership

于是：问题开始出现。

七、第一个隐藏问题：引用计数

一旦 clone，系统就必须维护：

refcnt

例如：

rte_mbuf_refcnt_update()

问题在于：refcnt：

本质上是：

atomic operation

例如：

__atomic_fetch_add()

而 atomic 在高频场景代价非常大。

因为：

它会导致：

• cache line lock
• pipeline stall
• memory ordering barrier

尤其：多核场景。

问题更严重。

八、为什么 atomic 在 DPDK 中特别贵？

因为：DPDK 本质是：

千万 PPS 高频循环

例如：

20Mpps

意味着：

每秒两千万次 refcnt 更新

于是：

CPU 会持续：

争夺 cache line ownership

最终：

大量 cycles 消耗在：

MESI cache coherency

而不是业务逻辑。

九、第二个隐藏问题：Cache Locality 崩溃

后来我们发现：使用 clone 后，cache miss 明显增加。

为什么？

因为多个 core 开始共享：

同一个 data buffer

于是：packet data 会在多个 core 之间：

来回迁移 cache line

这会导致：

cache line bouncing

最终：

CPU 大量时间消耗在：

cache coherency traffic

十、为什么 memcpy 有时候反而更快？

这是很多人最难理解的地方。

因为：

memcpy 虽然复制数据。

但它带来了：

独占 ownership

例如：

core A memcpy 后，新的 packet data 完全属于：

core A

于是：

后续处理 cache locality 极好。

而 clone：虽然不复制数据。

但会导致：

共享 cache line

最终：

cache coherency 开销可能远超 memcpy。

十一、第三个问题：Multi-Segment Packet

后来为了进一步减少 copy。

系统开始大量使用：

chained mbuf

即：

一个 packet 由多个 segment 组成。

例如：

mbuf1 -> mbuf2 -> mbuf3

看起来：这非常灵活。

但实际上：现代 CPU 极其讨厌：

pointer chasing

因为每次：

next pointer

都可能：

cache miss

十二、为什么链式 mbuf 会严重影响 Prefetch？

现代 CPU 非常依赖：

顺序访问

这样：

hardware prefetcher 才能工作。

但 chained mbuf 本质是：

随机跳转

于是：prefetch 完全失效。

最终：pipeline stall 暴涨。

十三、第四个问题：TX Recycle 开始失控

后来，系统又出现：

TX descriptor recycle 变慢

原因：

NIC 无法及时释放：

shared buffer

因为：

某些 clone packet refcnt 仍然不为 0。

于是：

mbuf 无法回收。

进一步导致：

mempool cache miss

最终：系统进入：

mempool starvation

十四、为什么零拷贝系统更容易出现 Tail Latency？

因为：

零拷贝通常意味着：

共享生命周期

而共享生命周期：

天然容易导致：

• refcnt stall
• recycle delay
• cache bouncing
• atomic contention

于是：

平均 PPS 可能很好。

但：

P99 latency

会明显恶化。

十五、真正的问题：现代 CPU 已经不是“算力瓶颈”

很多人还停留在：

CPU 算不动

时代。

实际上：

现代 Xeon 真正瓶颈是：

Memory System

包括：

• cache
• memory ordering
• NUMA
• LLC
• TLB

因此。

真正高性能的数据面的核心目标，已经不是：

减少计算

而是：

减少共享

十六、后来我们怎么重构？

后来，我们彻底推翻原方案。

核心原则：

1. 默认允许 memcpy

只要：

copy size 较小

例如：

• L2/L3 header
• metadata
• tunnel header

直接 copy。

因为：

小 copy 远比 cache bouncing 便宜

2. 避免 clone 跨核

原则：

谁创建 谁释放

避免：

shared ownership

3. 尽量避免 chained mbuf

优先：

contiguous packet

因为：

CPU 喜欢：

顺序内存

4. 优先优化 Cache Locality

真正的优化目标：

不是：

zero-copy

而是：

cache-hot

5. 避免频繁 atomic

尤其：高 PPS 场景。

atomic 往往比：

memcpy 更贵

十七、为什么 Linux Kernel 还能大量使用零拷贝？

因为：

Linux Kernel 优化目标通常是：

通用性

例如：

• 大文件传输
• TCP stream
• sendfile
• splice

这些场景：

packet lifetime 较长。

并且更偏：

throughput-oriented

而 DPDK 尤其小包场景，更偏：

ultra-low latency

两者优化目标：完全不同。

十八、真正的大规模 DPDK 优化，本质已经是 Cache Engineering

很多人以为：DPDK 优化是在：

优化网络

实际上。

真正的大规模数据面优化，最后都在优化：

• cache locality
• memory ownership
• NUMA
• memory ordering
• prefetch behavior
• pipeline stall

也就是说：

现代 DPDK 性能优化本质已经进入：

CPU 微架构领域

十九、总结

很多 DPDK 系统为了追求：

零拷贝

开始大量使用：

• clone
• indirect mbuf
• chained mbuf
• shared buffer

结果：系统反而：

• CPU 更高
• latency 更差
• cache miss 暴涨
• P99 抖动
• recycle 延迟

根本原因并不是：

DPDK 不够快

而是：

共享 ownership 破坏了 cache locality

真正优秀的数据面系统最终优化的已经不是：

copy 次数

而是：

CPU cache 与内存行为

而这，才是现代高性能 DPDK 系统最核心的本质。