↓ Skip to main content
Le Site de François
  1. Index/

DPDK

Telco Dpdk Dataplane Userspace Nfv Cloud-Native Upf Performance Open-Source
Table of Contents

The Data Plane Development Kit (DPDK) is an open-source set of libraries and poll-mode drivers (PMDs) that move packet processing from the kernel to userspace, enabling telco and cloud applications to achieve millions of packets per second per core with predictable latency. DPDK bypasses the traditional socket stack: applications busy-poll NIC queues (or virtio/vhost rings), use hugepages to reduce TLB misses, and pin threads to NUMA-local cores — a model suited to UPF, vRouter, CG-NAT, load balancers, and 5G user-plane functions where per-packet syscall overhead is unacceptable.

Core building blocks include Environment Abstraction Layer (EAL) for initialization and device discovery, mbuf memory pools, rte_ring queues, Hash/LPM/FIB libraries, eventdev and cryptodev for pipelines, and GPU/offload hooks in newer releases. PMDs exist for Intel, Broadcom, Mellanox/NVIDIA, Marvell, virtio, vhost-user (to OVS or VPP), and AF_XDP (hybrid kernel/userspace). Integration patterns:

PatternDescription
DPDK on SR-IOV VFDedicated NIC queues to container/VM
vhost-user / virtio-userConnection to OVS-DPDK or VPP
AF_PACKET / AF_XDPLower setup cost; moderate performance
DPDK in KubernetesUserspace CNI, device plugins, Sriov-DPDK

OVS-DPDK, FD.io VPP, TRex, and commercial CNFs (UPF, firewall) build on DPDK. Telco cloud-native packaging often combines DPDK dataplane containers with Kubernetes CPU isolation, hugepage emptyDir/limits, and IRQ tuning. Challenges: CPU consumption at low load (polling), debugging complexity, kernel bypass security surface, and version coupling between DPDK, NIC firmware, and distro kernels.

DPDK is maintained by the Linux Foundation with contributions from Intel, NVIDIA, Marvell, Red Hat, and operators; it remains the de facto foundation for high-performance userspace networking alongside eBPF/XDP for complementary kernel-side fast paths.

Additional Information
#

Related

SR-IOV

Telco Sr-Iov Nfv Cloud-Native Virtualization Dataplane Nic Kubernetes Performance
SR-IOV (Single Root I/O Virtualisation) is a PCI-SIG specification that lets one physical PCIe device (typically a NIC or accelerator) expose multiple lightweight Virtual Functions (VFs) — each assignable directly to a VM or container — while a Physical Function (PF) remains for management and global configuration. VFs bypass much of the hypervisor’s software switching path, delivering lower latency, higher throughput, and more deterministic behaviour than paravirtualised virtio alone — properties valued in telco NFV (vEPC, vRAN CU/DU, firewall, DPI) and in cloud-native packet workloads on Kubernetes.

5G Core (5GC)

Telco 5g 5gc Core-Network Service-Based-Architecture Nfv Cloud-Native Network-Slicing Upf Amf Smf Standards 3gpp
The 5G Core (5GC) is the packet core network architecture defined by 3GPP from Release 15 onward as the control and user-plane backbone of standalone 5G deployments. It replaces the Evolved Packet Core (EPC) of 4G LTE not through incremental evolution but through a deliberate architectural break: where the EPC was built around monolithic, hardware-bound network functions interconnected by point-to-point interfaces, the 5GC is designed from the ground up around a Service-Based Architecture (SBA) — every network function exposes its capabilities as a set of services over a common HTTP/2 bus (the Service-Based Interface, SBI), and any authorised consumer NF can discover and invoke those services through the NRF (Network Repository Function) without bilateral peering agreements or proprietary protocols. This shift reflects two structural requirements of 5G that EPC could not satisfy: network slicing — the ability to run logically independent end-to-end networks (each with its own QoS, isolation, and lifecycle) on shared physical infrastructure — and cloud-native deployment, where NFs run as containerised microservices on commodity compute, can be horizontally scaled, and are managed by standard Kubernetes-compatible orchestration rather than vendor-specific element managers. The 5GC also enforces a hard separation between Control Plane (CP) and User Plane (UP) — the CUPS principle inherited from 3GPP Release 14 and fully operationalised here — so that the UPF (User Plane Function) handling packet forwarding, QoS enforcement, and traffic anchoring can be distributed to the edge independently of the control logic, enabling ultra-low-latency and MEC scenarios without redesigning the control plane. The architecture is access-agnostic: the same 5GC serves NR (New Radio), eLTE, Wi-Fi (untrusted/trusted non-3GPP access), and fixed-wireless access through a unified N2/N3 reference point toward the access network and a common UE context model in the AMF.

Edge Computing

Telco Edge-Computing Mec 5g Upf Latency Cloud Industry-4.0 Kubernetes
Edge computing in telecommunications places compute, storage, and application execution close to users and devices — at cell sites, regional points of presence, or on-prem enterprise locations — rather than only in distant hyperscale data centres. The goal is to reduce end-to-end latency, limit backhaul load, satisfy data residency, and enable real-time applications (AR/VR, industrial control, V2X, video analytics) that are impractical with 50–100 ms round trips to central clouds. In 5G, edge is tightly coupled to the user plane: a local UPF on N6 breakout forwards traffic to an edge data network (DN) hosting MEC applications without hairpinning through the operator’s core hub.