为什么很多 DPDK 程序能跑满 100G，却撑不起 1000 万用户？——从运营商级 UPF 设计看数据面的真正挑战

一、一个看似矛盾的问题很多刚接触 DPDK 的开发者都有类似经历。写完第一个转发程序。压测结果非常漂亮64B Packet 100G Line Rate CPU 利用率 70%看到结果后。很多人会认为系统已经足够强大然而真正进入运营商场景后。却经常出现另一种现象100G 跑满 但用户数上不去甚至100万用户正常 500万用户开始异常 1000万用户直接失控这看起来非常奇怪。既然系统能够处理每秒上亿个数据包。为什么却无法支撑更多用户答案在于运营商网络最大的挑战 从来不是 Packet 而是 State二、Packet 很便宜State 很昂贵这是很多 DPDK 开发者最容易忽略的问题。一个 Packet 的生命周期可能只有几十微秒例如RX ↓ Lookup ↓ Forward ↓ TX完成转发后这个 Packet 就消失了。而 Session 不同。它可能持续数分钟 数小时 甚至数天例如一个 UE 上网过程建立 PDU Session ↓ 创建 TEID ↓ 创建 PDR ↓ 创建 FAR ↓ 创建 QER ↓ 持续运行这些状态会长期驻留在内存中。因此Packet 是瞬时资源 State 是长期资源三、为什么 Session 才是真正的成本中心假设每个用户维护PDR FAR QER URR Session Context Statistics保守估计1KB对于100万用户需要约 1GB看起来并不多。但如果达到1000万用户则需要10GB而且这还只是基础状态。如果开启 QoS开启计费开启流量统计开启 DPI状态规模会进一步扩大。此时问题已经不是能不能存下而是能不能高效访问四、100G 转发与千万 Session 是两种问题很多工程师误以为PPS 高 系统强实际上两者关联并不大。100G 转发关注Packet Processing而千万用户关注State Management例如一个简单 L3 ForwardLPM Lookup ↓ TX状态非常少。而 UPFTEID Lookup ↓ Session Lookup ↓ PDR Match ↓ QER Check ↓ URR Update ↓ Forward每个数据包都需要访问状态。这才是真正的挑战。五、运营商级系统为什么特别怕状态膨胀因为状态会带来三个问题。第一内存占用第二访问延迟第三管理复杂度其中最严重的是第二个。随着状态规模增长。状态越来越难保持在 Cache 中。大量访问开始落到DRAM于是CPU 大量时间开始等待内存。而不是处理数据包。六、从 Hash Table 到状态系统很多 Demo 中Flow Table 非常简单hash_lookup(teid);几十万条记录时。性能很好。但到了1000万 Session情况完全不同。此时Hash Table 已经不再是一个简单的数据结构。而变成状态数据库需要考虑插入删除更新老化恢复持久化很多项目失败的原因就在这里。开发团队只设计了查找却没有设计生命周期七、控制面与数据面的矛盾用户数量增加后。另一个问题开始出现。控制面需要新增规则 修改规则 删除规则而数据面正在百万 PPS处理流量。于是两个世界开始冲突。控制面希望随时修改数据面希望永远不要被打扰这就是运营商系统中最经典的矛盾。八、为什么共享状态会毁掉扩展性很多团队第一版架构global_session_table所有 Worker 共享。用户数少时。问题不明显。用户数增加后。开始出现锁竞争Cache 抖动更新冲突最终CPU 时间大量浪费在同步上。而不是业务处理上。九、真正的解决方案状态归属成熟 UPF 普遍采用Shared Nothing思想。例如TEID Hash ↓ Worker0 TEID Hash ↓ Worker1 TEID Hash ↓ Worker2每个 Worker拥有自己的状态。这样无锁 无共享 无同步系统扩展能力大幅提高。十、为什么运营商更关心 Session 而不是 PPS实验室测试通常关注最大 PPS但运营商真正关心的是最大用户数因为用户数决定收入能力而 PPS 只是资源利用率指标。对于运营商来说100G 100万用户和100G 1000万用户价值完全不同。十一、用户数增加后最先崩溃的是什么很多人以为CPU 会先崩。实际上最先崩的通常是管理系统例如Session 创建Session 删除状态同步配置下发这些操作的复杂度会随着用户数增长而迅速增加。十二、为什么 Session 创建比转发更难转发路径固定流程而 Session 创建涉及资源分配 状态初始化 规则关联 统计初始化并且需要保证一致性因此很多系统转发能力很强。但建链能力很弱。十三、运营商级产品真正考验什么很多开发者认为DPDK 高性能实际上。运营商真正考验的是持续运行能力例如连续运行半年期间用户持续上下线规则持续更新配置持续变化系统仍然稳定。这远比跑满 100G 更困难。十四、为什么 Demo 很容易产品很难因为 Demo 只证明算法成立而产品必须证明生命周期成立包括创建运行修改删除恢复整个过程。十五、未来数据面的核心竞争力随着5G6G云核心网的发展。未来数据面的竞争重点正在发生变化。过去比 PPS现在比 Session未来比状态管理能力谁能管理千万 Session 亿级 Flow 长期稳定运行谁才能成为真正的运营商级产品。十六、总结很多 DPDK 项目能够轻松跑满 100G。但最终无法成为运营商产品。根本原因在于它们解决了 Packet 问题 却没有解决 State 问题Packet 是瞬时的。State 是长期的。Packet 处理决定系统性能上限。State 管理决定系统规模上限。当系统从实验室走向真实网络时。真正的挑战不再是每秒处理多少包而是能管理多少用户 能维护多少状态 能稳定运行多久这也是从 DPDK Demo 走向运营商级 UPF 产品过程中最关键的一次认知升级。