Skip to content
TOSSI Foundation TOSSI

By TOSSI · · 7 min read

The 5G Core went cloud-native everywhere except the user-plane fast path, which stayed tied to Linux kernel internals. By moving GTP-U processing into three compact eBPF programs and leaving Open vSwitch completely unmodified, we turn the Magma user plane from a kernel artifact into a portable application artifact.

Cloud-native eBPF datapath for the Magma 5G Core user plane: the Magma control plane (PipelineD, SessionD, MobilityD, MME/AMF, subscriberdb), an event-driven eBPF session adapter reconciling state into pinned BPF maps, three eBPF traffic-control programs (gtp_decap, gtp_mark, gtp_encap), an unmodified Open vSwitch bridge classifying on packet marks, and pinned BPF maps for session, config, and stats.
The cloud-native eBPF datapath for the Magma 5G Core user plane. Three eBPF programs handle GTP-U processing while an unmodified Open vSwitch keeps doing flow classification and forwarding; the QoS Flow Identifier travels as a standard packet mark, so OVS needs no custom protocol field.

The Last Barrier to a Truly Cloud-Native 5G Core

The 5G Core has undergone a remarkable transformation over the last decade. Network functions that once relied on dedicated appliances now run as containers, scale through Kubernetes, and are deployed across commodity infrastructure from centralized data centers to the network edge. This cloud-native evolution has fundamentally changed how telecom infrastructure is built and operated.

Yet despite this progress, one critical component remained firmly rooted in the past: the user-plane fast path. Every subscriber packet traverses this path. It is responsible for GTP-U encapsulation and decapsulation, QoS enforcement, and forwarding traffic between the Radio Access Network (RAN) and external data networks. While the rest of the core embraced portability, automation, and continuous deployment, the datapath often remained tightly coupled to Linux kernel internals.

This dependency became one of the last architectural barriers preventing the 5G Core from becoming truly cloud-native.

The Hidden Cost of Kernel Coupling

Open vSwitch (OVS) has become the de facto software switch for many cloud-native and telecom deployments because of its flexibility, programmability, and mature ecosystem. However, stock Open vSwitch does not natively understand GTP-U or the 5G QoS Flow Identifier (QFI). To support these capabilities, many deployments traditionally relied on:

  • Forked Open vSwitch implementations
  • Out-of-tree kernel modules
  • Custom protocol match fields
  • Kernel-specific datapath rebuilds
  • Long-term maintenance of downstream patches

While functional, this approach introduces significant operational overhead. Routine operating-system upgrades become qualification exercises. Security patches may need to wait until custom kernel modules are rebuilt and revalidated. The datapath becomes tied to specific kernel versions instead of evolving alongside the rest of the cloud-native stack.

The issue was never simply about throughput. The real challenge was architectural coupling.

Rethinking the Datapath

Instead of extending Open vSwitch further, we approached the problem differently. Rather than teaching Open vSwitch to understand GTP-U, we moved tunnel processing into three compact eBPF programs while allowing Open vSwitch to continue doing what it already does best: flow classification and packet forwarding. This fundamentally changes the architecture without disrupting the existing control plane.

The datapath consists of three focused eBPF components:

  • Ingress processing (gtp_decap): validates incoming GTP-U packets, extracts subscriber context, removes tunnel headers, and retrieves the QoS Flow Identifier (QFI).
  • Metadata seam (gtp_mark): restores packet metadata, allowing Open vSwitch to classify traffic using standard packet marks instead of custom protocol extensions.
  • Egress processing (gtp_encap): reconstructs GTP-U packets, restores subscriber context, and forwards traffic toward the radio network.

A key architectural decision was to transport the QoS Flow Identifier as standard packet metadata rather than introducing new protocol fields inside Open vSwitch. As a result, Open vSwitch remains completely unmodified. There are no custom protocol extensions, no downstream forks, and no kernel-specific datapath rebuilds.

eBPF work breakdown: an orchestration layer (tc_loader, ebpf_session_adapter.py, ebpf_control.py, systemd services) above three traffic-control programs (gtp_decap on eth1 ingress, gtp_mark on gtp_veth0 ingress, gtp_encap on gtp_veth1 ingress) around an unmodified OVS bridge, plus three pinned shared maps for session, config, and stats. Side panels detail the program topology, the QFI seam, and fail-closed behaviour.
The eBPF work breakdown. Three traffic-control programs carry the live datapath, an orchestration layer loads and reconciles them, and three pinned BPF maps hold session, config, and statistics state. The QFI seam moves the flow identifier between skb->mark and the packet mark so OVS classifies without a custom field.

Keeping the Control Plane Untouched

Redesigning the datapath should not require redesigning the control plane. One of the primary goals of this work was to preserve the existing Magma architecture while replacing only the forwarding implementation.

Subscriber sessions continue to be created and managed by the existing controller. A lightweight synchronization layer mirrors the required session state into pinned eBPF maps, allowing the datapath to retrieve subscriber information without changing signaling behavior. This approach preserves:

  • Existing Magma services
  • Existing container images
  • Existing deployment workflows
  • Existing subscriber management

Only the forwarding implementation changes. Everything above it remains intact.

From Kernel Artifact to Application Artifact

Perhaps the most important outcome of this work is not higher throughput; it is portability. Historically, the forwarding path existed as a kernel artifact. Supporting new Linux versions required rebuilding kernel modules, maintaining downstream patches, and qualifying every supported kernel release.

By moving GTP-U processing into verified eBPF bytecode, the forwarding logic becomes an application artifact loaded through stable kernel interfaces. This changes the operational model:

  • Kernel upgrades no longer imply datapath rebuilds.
  • Operating systems can be patched independently.
  • Open vSwitch remains closer to upstream.

The user plane becomes significantly easier to deploy, maintain, and evolve across different environments.

Validation Across an Open Telecom Stack

A new datapath architecture is only meaningful if it works beyond isolated software environments. The eBPF-based implementation was validated across an end-to-end open telecom ecosystem comprising the Magma 5G Core together with a range of RAN configurations:

  • OCUDU (CU/DU split)
  • OAI (CU/DU split)
  • OCUDU (L3–L2) + xFAPI + OAI (L1)
  • Commercial O-RAN-compliant radios
  • Software-defined radios (SDRs)
  • Live handset traffic

This validation demonstrated that the architecture integrates seamlessly with existing open-source telecom components while preserving the existing control plane and eliminating the dependency on kernel-specific Open vSwitch modifications.

Why This Matters

This work is not simply about replacing kernel code with eBPF. It demonstrates that one of the final architectural constraints preventing a fully cloud-native 5G Core can be removed without redesigning the surrounding ecosystem. The resulting architecture provides several practical advantages:

  • No custom Open vSwitch fork
  • No out-of-tree kernel module
  • Portable datapath across Linux kernels
  • Independent operating-system updates
  • Reduced maintenance overhead
  • Simpler deployment lifecycle
  • Better alignment with cloud-native practices

More importantly, it changes how the user plane is managed. Instead of being tightly coupled to a specific Linux kernel, the forwarding path becomes portable, maintainable, and aligned with the same cloud-native principles that already define the rest of the 5G Core.

Open Source

This work has been developed as part of the TOSSI Foundation and is available to the community for review, experimentation, and contribution. If you are working on Magma, Open RAN, cloud-native telecom infrastructure, or eBPF, we would welcome your feedback, testing, and collaboration. The future of open telecom infrastructure will be built through shared innovation, and this is one step toward that future.