DPDK高性能交换机深度实践：一次Mbuf External Buffer设计缺陷引发的性能雪崩

一、故障背景

某大型数据中心部署基于DPDK的软件交换机。

主要功能：

• VXLAN Gateway
• EVPN Leaf
• ACL
• Telemetry
• ERSPAN Mirror

硬件配置：

项目	配置
CPU	Intel Xeon Gold 6430
网卡	Intel E810
DPDK	23.11
PMD Core	32
Hugepage	1GB

上线压测：

96Mpps

稳定运行。

---

某次升级后新增：

ERSPAN镜像

功能。

---

随后开始出现：

96Mpps
↓
84Mpps
↓
76Mpps
↓
68Mpps

---

但：

CPU = 100%

始终如此。

---

二、第一轮排查

检查：

rte_eth_stats_get()

结果：

imissed=0
ierrors=0
rx_nombuf=0

正常。

---

RSS：

32 Queue均衡

正常。

---

ACL：

Lookup Cycles稳定

正常。

---

FIB：

DIR24_8稳定

正常。

---

所有传统方向均被排除。

---

三、一个关键现象

问题只在：

开启ERSPAN

时出现。

关闭后：

96Mpps

恢复。

---

说明：

问题与：

Packet Copy

有关。

---

四、开发团队的优化方案

为了避免复制数据包。

采用：

rte_pktmbuf_attach_extbuf()

---

即：

External Buffer模式。

---

如下图：

---

原始包：

mbufA
  ↓
buffer

---

镜像包：

mbufB
  ↓
同一个buffer

---

避免：

memcpy()

---

理论上性能更好。

---

五、External Buffer工作原理

普通模式：

mbuf
+
data buffer

绑定。

---

释放：

rte_pktmbuf_free()

直接回收。

---

External Buffer模式：

mbufA
      \
       buffer
      /
mbufB

---

需要：

RefCnt

管理。

---

六、问题开始出现

交换机每秒：

90M+
Packets

---

每个镜像包：

RefCnt++

---

释放：

RefCnt--

---

理论上：

没问题。

---

但现场Perf显示：

atomic operations

激增。

---

七、RefCnt为什么昂贵

引用计数：

rte_mbuf_ext_refcnt_update()

内部：

atomic_add()

---

意味着：

Cache Line Ownership Transfer

---

如下图：

---

八、真正的问题：Cache Line Bounce

假设：

Core5：

Mirror Flow A

---

Core12：

Mirror Flow B

---

共享：

同一个RefCnt

---

结果：

缓存线：

Core5
↓
Core12
↓
Core5
↓
Core12

不断迁移。

---

形成：

Cache Bounce

---

九、Perf证据

统计：

perf stat

---

发现：

mem_load_retired.l3_miss

增长：

5倍

---

同时：

lock instructions

增长：

8倍

---

十、第二层放大效应

不仅引用计数。

回收路径也被影响。

---

正常：

free
↓
mempool

---

External Buffer：

free
↓
refcnt check
↓
callback
↓
mempool

---

增加：

分支预测失败

---

十一、第三层放大效应

由于：

Mirror Traffic

占比不断增加。

---

系统出现：

External Buffer
占总包量70%

---

导致：

atomic hotspot

越来越严重。

---

十二、为什么CPU始终100%

因为：

PMD：

while(1)
{
    rte_eth_rx_burst();
    process();
    rte_eth_tx_burst();
}

永不休眠。

---

CPU：

100%

正常。

---

但：

Cycles/Packet

不断增长。

---

十三、根因闭环

完整链路：

ERSPAN
    ↓
External Buffer
    ↓
RefCnt Atomic
    ↓
Cache Bounce
    ↓
L3 Miss增加
    ↓
Cycles/Packet增加
    ↓
PPS下降

---

十四、如何验证

统计：

perf stat

关注：

lock instructions
cache-to-cache transfer

---

使用：

perf c2c

分析：

热点Cache Line

---

即可发现：

RefCnt字段

成为热点。

---

十五、优化方案

方案一

小包直接复制。

不要共享Buffer。

---

即：

rte_pktmbuf_copy()

---

对于：

64B~256B

往往更快。

---

方案二

大包使用External Buffer。

---

例如：

>512B

启用共享。

---

方案三

Per-Core Mirror Queue。

避免：

跨Core共享RefCnt

---

方案四

Mirror独立Pipeline。

如下图：

---

避免：

Forward Path
Mirror Path

争用同一生命周期。

---

十六、优化结果

优化前：

指标	数值
PPS	68M
LLC Miss	18%
Atomic Ops	8×
RTT P99	4.8ms

---

优化后：

指标	数值
PPS	95M
LLC Miss	4%
Atomic Ops	1×
RTT P99	0.8ms

---

核心知识点总结

1

零拷贝不一定更快。

---

2

External Buffer节省的是：

Memory Copy

成本。

---

但增加了：

Cache Coherency

成本。

---

3

在几十Mpps以上场景：

Atomic Cost

往往比：

Memcpy Cost

更昂贵。

---

4

共享数据结构比复制数据更容易成为瓶颈。

---

5

PMD线程100%运行时。

真正要看：

Cycles Per Packet

而不是CPU利用率。

---

6

DPDK中的性能问题很多来自：

生命周期管理

而非数据处理逻辑。

---

7

高性能交换机设计中：

“减少共享”往往比“减少复制”更重要。

这是一个与本项目此前所有文章完全不同的方向，属于Mbuf架构与生命周期管理层面的性能问题，也是很多高端交换机、流量镜像设备和Packet Broker产品在后期扩容时才会暴露出来的深层瓶颈。