从100Gbps掉到15Gbps：一次高性能网关性能瓶颈的完整定位与架构演进

一、问题现象

我前几年曾经为某运营商设计并落地一套UPF架构。当项目进入集成测试阶段：

硬件配置：

• Intel Xeon Gold 双路CPU
• 2×100G Intel E810网卡
• DPDK 20.11
• Linux Kernel 5.15

系统架构如下：

设计目标：

• 单机100Gbps
• 64字节报文
• 双向转发

实际压测结果：

最诡异的是：网卡没打满、内存也没打满，但是吞吐量就是上不去。

这类问题在高性能网关开发中极其常见。

二、第一步定位：CPU到底在干什么

首先使用perf采样：

perf top

热点函数：

45% rte_ring_enqueue_burst 18% rte_ring_dequeue_burst 12% rte_hash_lookup_bulk 8% rte_pktmbuf_alloc_bulk

发现一个奇怪现象：

真正的数据包处理逻辑：

process_gtpu_packet()

只占不到10%。

CPU时间主要消耗在：

Ring Hash Mbuf

这些基础设施上。

说明问题不在业务逻辑。

而在架构设计。

三、Dispatcher成为瓶颈

当前架构：

RX | V +---------------+ | Dispatcher | +---------------+ / / / / / / V V V V V V Worker Worker

Dispatcher负责：

收包 解析TEID 计算Hash 决定Worker 入Ring

Worker负责：

GTP-U处理 PDR查找 FAR处理 转发

看起来很合理。

但问题来了。

假设：

100Gbps 64Byte

对应：

148.8 Mpps

Dispatcher必须完成：

148.8M次TEID解析 148.8M次Hash 148.8M次Ring操作

实际上Dispatcher已经成为整个系统的单点瓶颈。

架构如下：

RX | V Dispatcher | ---------------- | | | | | | V V V V V V Worker Worker Worker

所有流量必须经过Dispatcher。

这是典型的：

串行入口 并行出口

架构。

四、缓存一致性风暴出现

进一步观察：

perf c2c

结果显示：

rte_ring_prod_tail rte_ring_cons_head

大量Cache Line Bounce。

原因：多个Core同时访问Ring。

例如：

Dispatcher ↓ Worker0 Dispatcher ↓ Worker1 Dispatcher ↓ Worker2

Dispatcher不断修改：

prod_tail

Worker不断修改：

cons_head

导致：

Core0 Cache ↓ Invalidate ↓ Core3 Cache ↓ Invalidate ↓ Core0 Cache

形成缓存乒乓。

如下图：

此时CPU利用率看起来不高。

但实际上大量周期浪费在：

MESI协议同步

五、NUMA问题浮出水面

继续检查：

dpdk-proc-info

发现：

网卡: NUMA Node 0 Worker: NUMA Node 1

即：

NIC --> Socket0 Worker --> Socket1

每个数据包都发生：

PCIe DMA ↓ Socket0 Memory ↓ QPI/UPI ↓ Socket1 CPU

跨NUMA访问。

现代双路服务器：

本地访问：80ns 跨路访问：150~200ns

看似只差100ns。

但：

100Mpps

情况下：

影响极其巨大。

六、真正的问题：线程模型设计错误

经过分析发现：

系统采用的是：

RX ↓ Dispatcher ↓ Worker ↓ TX

四阶段流水线。

这种设计来自传统软件架构思想：

模块解耦 职责分离

但在100G数据面场景下：

这是错误的。

因为每经过一个阶段：

都会产生：

Ring切换 Cache失效 Core迁移

例如：

RX Core ↓ Worker Core ↓ TX Core

数据包生命周期中：

同一个mbuf被多个CPU访问。

缓存命中率急剧下降。

七、现代高性能网关的设计原则

真正高性能的架构：

RX Queue0 → Core0 → TX Queue0 RX Queue1 → Core1 → TX Queue1 RX Queue2 → Core2 → TX Queue2

如下：

即：

Run-To-Completion

模型。

特点：

一个包只属于一个CPU

RX 处理 转发 TX

全部在同一个Core完成。

避免：

Ring Lock Cache Bounce

八、为什么VPP性能高

VPP采用：

Vector Processing

思想。

不是：

1包处理一次

而是：

32包 64包 128包

一起处理。

例如：

while(nb) { prefetch(pkt[i+4]); process(pkt[i]); }

CPU执行过程：

Load Load Load Load Compute Compute Compute

形成流水线。

减少：

Cache Miss Branch Miss

现代CPU最怕：

等待内存

而不是计算。

九、重新设计UPF数据面

经过重构后：

采用：

RSS ↓ N3 Worker ↓ F-TEID Hash ↓ PDR/FAR ↓ N6 TX

原则：

原则1

Dispatcher只做最轻量工作

解析TEID 计算Worker

禁止：

PDR查找 业务逻辑

原则2

Session固定归属Worker

TEID % WorkerNum

保证：

同一UE 同一CPU

避免状态同步。

原则3

NUMA绑定

--socket-mem=4096,4096

Worker与网卡同NUMA。

原则4

批处理

rte_eth_rx_burst()

每次：

32~64包

一起处理。

原则5

避免跨线程Ring

能不用：

rte_ring

就不用。

因为：

一次Ring ≈几十到上百CPU Cycle

100Mpps下代价巨大。

十、优化结果

优化前：

优化后：

继续优化：

• Hugepage布局
• NUMA亲和
• Prefetch
• SIMD

最终达到：

95~98Gbps

接近线速。

十一、高性能网关架构设计的本质

很多开发者认为：

性能 = 算法

实际上在100G时代：

真正决定性能的往往不是算法。

而是：

缓存命中率 NUMA访问 线程模型 数据流向

一个Hash查找可能只需要：

20ns

但一次跨NUMA访问可能需要：

200ns

一个业务逻辑可能只占：

10%

而线程间Ring切换可能占：

50%

因此，高性能网关设计最重要的一条原则是：不要让数据包在CPU之间旅行，而要让CPU拥有数据包。

当系统达到100Gbps甚至200Gbps时，决定性能上限的已经不再是代码是否优雅，而是缓存、NUMA和线程模型是否符合现代CPU架构。真正优秀的数据面设计，往往不是增加更多线程，而是减少数据包在不同线程之间的流动次数，让一次缓存加载产生最大的价值。