想了解如何利用eBPF和XDP技术彻底重塑5G数据平面的性能，同时解决传统用户面功能（UPF）在延迟和吞吐量上的瓶颈吗？从内核级优化到实际性能基准测试，这些创新方法将重新定义下一代网络的核心能力。
本文译自 Rewiring the 5G Data Plane: XDP/eBPF and UPF[1]。
在5G网络中，用户面功能（UPF）是数据平面的核心，负责数据包路由、QoS（服务质量）执行和策略应用。你可以把它想象成5G网络内部的智能交通指挥，快速将数据引导至正确路径，确保你的在线体验流畅无阻。
传统上，UPF在用户空间运行，依赖内核网络栈处理数据包。这不可避免地引入了上下文切换、内存拷贝和系统调用带来的额外延迟。
与此同时，应用程序对性能的期望持续攀升，物联网传感器、智能手机等连接设备数量爆炸式增长，都对网络提出了更低延迟和更高吞吐量的严苛要求。于是，一个问题自然浮现：eBPF能帮助运营商满足这些需求吗？
为了理解eBPF在何处能真正发挥作用，我们首先需要拆解UPF在5G核心网中的具体职责。
一个UPF实例主要处理一系列高速的网络数据包级任务：
- GTP-U隧道封装/解封装：封装或解封数据包，使其能在5G核心网内正确路由。
- IP转发/NAT：将数据包转发至正确目的地，并在必要时执行网络地址转换。
- QoS和流量监管：确保视频通话、关键任务数据等高优先级流量获得所需的带宽和低延迟。
- 合法拦截：为法律合规目的，静默复制指定流量而不中断用户会话。
- 流量分类：检查数据包头，决定流量应保留在核心网内、发送到边缘，还是应用特殊规则。
- 用量计量：统计每个用户或服务的数据消耗量，用于计费或使用情况跟踪。
考虑到物联网设备、工业传感器、智慧城市乃至自动驾驶汽车的快速发展，现代UPF必须变得更加高效——它需要具备适应性、可扩展性，并能应对更复杂的工作负载。
一个理想的UPF应具备以下特征：
- 超低延迟 (URLLC)：支持亚毫秒级数据包处理，满足实时关键任务应用需求。
- 高吞吐量：具备多Gbps处理能力，且每包开销极小。
- 动态可编程性：能够实时插入新策略、计量规则、流量整形功能或深度包检测（DPI）钩子。
- 高效的流与会话管理：通过快速表查找实现GTP-U隧道处理和PFCP会话控制。
- 强大的安全性与切片隔离：内置访问控制列表（ACL）、切片级策略执行、防欺骗和速率限制。
- 丰富的可观测性与遥测：原生支持追踪、流统计，并能将指标导出至Prometheus、Grafana等监控栈。
- 硬件无关性：优化适配标准网卡，不依赖专用智能网卡或仅支持特定框架的设置。
- 弹性与容错：支持平滑故障转移、零丢包升级，并在故障时具备自愈能力。
那么，传统方案存在哪些不足呢？
大多数基于软件的UPF在用户空间处理流量，这意味着所有网络数据在被处理前都需要经历：
- 完整的内核网络栈遍历：包括路由、流量控制（tc）、Netfilter等。
- 分配和复制
sk_buff 缓冲区：以完成每个数据包的转换。
- 内核与用户空间之间的上下文切换：用以应用策略或转发流量。
这种设计虽然功能完整，但对追求极致性能的场景造成了显著影响：
- 高延迟：数据包遍历内核网络栈，为每个数据包增加了微秒级的额外延迟。
- 吞吐量瓶颈：在高每秒数据包（PPS）速率下，CPU迅速饱和，限制了实现多Gbps吞吐量的可能。
为了在一定程度上克服这些缺点，运营商引入了数据平面开发套件（DPDK）。DPDK通过将网络数据包直接从网卡绕过内核转发到用户空间进行处理，从而规避了内核开销。
然而，DPDK本身也存在一些明显的局限性：
- 硬件依赖性：需要支持特定驱动（如
vfio-pci， uio）的网卡。
- 有限的可观测性：与Linux原生工具链或可观测性栈集成不佳。
- 扩展性僵化：受限于硬件特定的扩展瓶颈，弹性较差。
这些局限性将我们的目光引向了eBPF。
我们不会深入eBPF的所有细节，但其中一种名为XDP（eXpress Data Path）的eBPF程序类型与我们的主题高度相关。XDP允许将eBPF程序直接附加到网络驱动程序的早期接收路径上。
观察上图最左侧，在(start)点之后紧跟着出现的便是XDP/eBPF模块。这是XDP钩入网卡驱动程序的点——位于数据包通过alloc_skb()传递给内核之前。换言之，这是Linux内核中最早、最快的数据包拦截点。
那么，这一点为何重要？
通过编写eBPF XDP程序，你可以：
- 绕过Netfilter、队列规则（qdisc）、
sk_buff分配及完整路由逻辑等开销较高的处理层。
- 直接在网卡驱动层面实现线速过滤、DDoS缓解乃至数据包转发逻辑。
这使得基于eBPF/XDP的UPF在设计上就比依赖完整内核栈或Netfilter钩子的传统用户态UPF快几个数量级。
当然，理论需要实践验证。
为了支持上述观点，我们来看一组针对 edgecomllc eupf[5]、Open5gs-UPF[6]、Free5gc-UPF[7] 和 UPG-VPP[8] 的性能基准测试对比。具体的测试步骤和结果可以在相关的 GitHub仓库[9] 中找到。
从基准测试中，我们可以得出一些关键结论：
- 处理模型至关重要：将数据包保留在内核空间（eBPF/XDP）或通过轮询模式驱动（DPDK/VPP）直接处理NIC队列，消除了限制用户空间TUN/TAP设计的系统调用和上下文切换开销。
- eUPF在带宽上表现突出：它在双向测试中均维持了约9.6 Gbps的吞吐量，比Open5GS高出6–8倍，比UPG-VPP高出约30%，而其全部处理逻辑都运行在附加到XDP的eBPF程序上。
- UPG-VPP延迟最低：其0.157毫秒的平均延迟比其他方案低约25%，这得益于DPDK的忙轮询数据路径，尽管虚拟机层面的virtio接口限制了其总吞吐量达到线速。
- free5GC实现了性能平衡：通过将GTP处理推送到内核模块，其性能比Open5GS高出约4倍，但在数据包速率超过约50万pps时，仍落后于基于DPDK或eBPF的方案。
- 用户空间TUN/TAP是Open5GS的瓶颈：每个数据包都需要两次复制和一次上下文切换，导致其性能上限约在1.2 Gbps。这对于实验室演示足够，但难以满足实际边缘部署需求。
这些结果可以作为重要的方向性指导：若追求线速N6接口和低抖动，应优先考虑eUPF或UPG-VPP；若需要快速的功能验证，可以使用Open5GS；而free5GC的内核UPF则提供了一个不错的折中方案。这背后体现的是对不同容器化与云原生部署场景下系统设计的深度思考。
将eBPF和XDP技术应用于5G UPF数据平面，代表了一种从根本上提升网络性能和灵活性的范式转变。它通过内核旁路和早期包处理，为满足5G URLLC和大规模物联网连接的需求提供了强有力的技术支撑。
引用链接
[1] Rewiring the 5G Data Plane: XDP/eBPF and UPF: https://ebpfchirp.substack.com/p/rewiring-the-5g-data-plane-xdpebpf
[2] Satyam Dubey: https://www.linkedin.com/in/satyam-dubey-142598258/
[3] 数据平面开发套件 (DPDK): https://www.dpdk.org/
[4] XDP (eXpress Data Path) eBPF 程序类型: https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_XDP/
[5] edgecomllc eupf: https://github.com/edgecomllc/eupf
[6] Open5gs-UPF: https://github.com/open5gs/open5gs
[7] Free5gc-UPF: https://github.com/free5gc/go-upf
[8] UPG-VPP: https://github.com/travelping/upg-vpp
[9] GitHub 仓库: https://github.com/s5uishida/simple_measurement_of_upf_performance_9
发表于 3 小时前
|
查看: 4|
回复: 0
