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

SR-IOV

Telco Sr-Iov Nfv Cloud-Native Virtualization Dataplane Nic Kubernetes Performance
Table of Contents

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.

Architecture: the NIC firmware schedules DMA and queues per VF; the hypervisor (KVM, ESXi) or container runtime maps VFs via VFIO or vendor plugins into guests. SR-IOV Network Virtualisation (SR-IOV NV) extensions address VEPA, hairpin, and overlay interactions with Open vSwitch or hardware offload. In Kubernetes, Multus, SR-IOV Network Operator, and device plugins attach VFs to Pods as secondary interfaces — often the data plane while a management interface stays on the CNI overlay.

ApproachTypical latency / CPUUse case
virtioHigher software costGeneral workloads, flexibility
SR-IOV VFNear bare-metal NICUPF, vDU, high PPS VNFs
DPDK on VFUserspace poll-mode on dedicated queuesTelco packet pipelines

Trade-offs include reduced mobility (VF pinning to host/NIC), finite VF counts per port, operational complexity (driver, firmware, NUMA alignment), and security boundaries (VF isolation depends on NIC and IOMMU). DPDK commonly runs atop SR-IOV VFs; PTP hardware timestamping may require specific NIC families. SmartNICs / DPUs (BlueField, IPU) extend the model with programmable pipelines and ARM control cores, blurring the line between SR-IOV and inline acceleration.

Additional Information
#

Related

DPDK

Telco Dpdk Dataplane Userspace Nfv Cloud-Native Upf Performance Open-Source
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.

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.