How to Run DPDK Workloads on Kubernetes with SR-IOV and Multus CNI

Introduction

If you're working on a system that needs to process millions of packets per second, whether a telco gateway, a trading engine, or a streaming backbone pulling in millions of concurrent viewers, you've probably hit the same wall: the Linux kernel networking stack was never designed for this. Linux and its networking stack emerged in the early 90s, then reshaped themselves in the early 2000s to serve high-traffic websites and the infrastructure behind them. It wasn't enough. Over the years, the kernel and its networking stack kept improving. But for the near-realtime systems we're talking about here, it still fell short.

And yet, the Linux networking stack remains an engineering masterpiece. It flawlessly handles routing, firewalling, socket management, and hundreds of other network and IO-related tasks. But every packet passing through that stack carries a hardware cost. A context switch, a memory copy, an interrupt. At 1 Gbps, you'll barely notice, since modern NICs handle much of the work on their own. At 10, 25, or 100 Gbps, however, it becomes your biggest bottleneck.

DPDK was born to solve exactly this problem.

Developed by Intel and later donated to the Linux Foundation, DPDK (Data Plane Development Kit) takes a radical approach to packet processing. It bypasses the kernel and, with it, the entire Linux networking stack. It moves processing into userspace. It polls instead of relying on interrupts. It pins dedicated CPU cores. The result? Latency drops from hundreds of microseconds to single digits. Throughput scales linearly with core count.

But as we go deeper into cloud-native architectures, we keep asking ourselves:

What happens to DPDK when workloads live inside Kubernetes?

That's exactly what this post is about. The world of DPDK is an unusual one; read on carefully.

DPDK: What It Is and What It Isn't

Before going any further, let's get the fundamentals straight, because DPDK is one of the most misunderstood technologies out there. Let's clear up the misconceptions first.

Kernel-Bypass and Userspace Networking

In a traditional Linux networking setup, every incoming packet passes through the kernel. The NIC (network interface card) receives the packet and fires an interrupt; the kernel copies the packet from NIC memory into kernel space, then into userspace. Userspace, at its core, is the layer where network-based applications running on Linux live and get direct access to data. Only then does your application see the packet. Under heavy load, these steps pile up fast: multiple memory copies, CPU context switches, and syscalls all turn into a real problem.

DPDK eliminates most of these steps. Using Poll Mode Drivers (PMDs) that run entirely in userspace, it accesses NIC hardware directly. No interrupts. No kernel involvement in the data path. Your application talks to the NIC almost directly. Some NIC vendors take this even further, pairing DPDK-compatible drivers with onboard ToE (TCP Offload Engine) chips.

The performance results are genuinely striking:

Note: On the kernel stack, a 10 Gbit NIC running at ~70% interrupt utilization (as an example) typically sees 7-8 Gbps, while DPDK hits a clean 10 Gbps.

DPDK vs XDP vs RDMA

These three often get mixed up, so let's look at brief definitions:

• XDP (eXpress Data Path): A packet path that runs inside the kernel, just before the network stack. A middle road: faster than standard kernel networking, but not a full bypass. Ideal for firewalling and load balancing scenarios.
• RDMA (Remote Direct Memory Access): Focuses on memory-to-memory transfers between machines, bypassing the CPU entirely. Common in HPC and storage networks, and lately increasingly common in GPU cluster scenarios as well. The goal is speed through direct memory access.

• DPDK (Data Plane Development Kit): Full userspace packet processing. Maximum flexibility and performance for complex packet manipulation. An ideal fit for virtually any network-centric application or appliance.

To put it in perspective: XDP is the fast lane on the kernel highway. RDMA is a private access road between machines. And DPDK is the soundest way to build a road entirely your own.

What DPDK Is Not

• It's not a magic fix. It requires dedicated CPU cores, hugepages memory configuration, and compatible NICs running purpose-built drivers.
• It's not easy to operate, or to develop for. The learning curve is steep. Debugging userspace packet processing is far harder than working with the standard Linux networking stack, and it demands purpose-built applications.
• It's not always necessary. If you don't need to process millions of packets per second, the kernel stack is probably fine.

Real-World Examples That Demand More

No technology emerges on its own, context-free, in a lab. Every technology is born out of a real-world need, a context. DPDK is exactly that kind of technology: born out of necessity.

Telco & 5G

5G networks are fundamentally software-defined. The User Plane Function (UPF), responsible for routing user traffic between the radio network and the internet, has to process millions of packets per second at sub-millisecond latency. A single 5G base station can generate traffic surges capable of saturating a standard kernel networking stack within seconds.

Projects like ONAP and OpenAirInterface rely heavily on DPDK for exactly this reason. A typical 5G UPF has to sustain 20-100 Gbps of throughput at under 1ms latency. The Linux kernel stack tops out well below that at this scale.

Fintech & High-Frequency Trading (HFT)

In algorithmic trading, microseconds matter. A strategy that reacts 10µs faster than a competitor can translate into millions of dollars in annual profit. With DPDK, latency drops from ~50-100µs down to 1-5µs: a 10-50x improvement that feeds directly into competitive advantage. This matters enormously

for central exchange platforms, payment-accepting fintech startups, and especially high-frequency trading infrastructures.

Media & Video Streaming

Large-scale video streaming platforms have to cope with extremely high packet rates. When millions of viewers tune into the same broadcast at once, with playback expected to be seamless and quality scaling up with available bandwidth, packet rates spike suddenly and have to land with low latency, putting serious strain on the network.

DPDK lets these platforms run on commodity x86 hardware instead of extremely expensive purpose-built appliances, dramatically cutting infrastructure costs while preserving quality of service.

Online Gaming

Modern multiplayer games are extraordinarily latency-sensitive. You've almost certainly heard this straight from a gamer's mouth: "the game is LAGGING." That phrase has become today's umbrella term for network-induced delay. Especially in battle royale, real-time strategy, and online FPS titles, game server infrastructure relies on DPDK-based packet processing to keep game state synchronization tight and consistent across thousands of concurrent players.

The Common Thread

Across all these industries and infrastructures, the same requirements surface and the same pattern repeats: high packet rates, low latency requirements, and commodity hardware. DPDK sits at the intersection of all three, letting software do what once required dedicated chips and custom silicon.

Understanding Kubernetes Networking

Before we talk about wiring DPDK into Kubernetes, we need to understand what Kubernetes networking actually does and where its limits begin.

The Kubernetes Networking Model

Kubernetes follows a flat networking model. Every pod gets its own IP address. Pods communicate with each other directly, without NAT. Services abstract pod IPs behind a stable virtual IP. It's simple, elegant, and designed for general-purpose workloads. For sub-millisecond latency, though, a flat networking model produces considerable overhead. What the Kubernetes networking model carries with ease is web applications, websocket applications, API-driven services, and general-purpose workloads.

CNI: The Plugin Layer

Kubernetes doesn't implement networking itself. It delegates the job to CNI (Container Network Interface) plugins.

The Performance Ceiling

Even the best CNI plugins, Cilium and eBPF included, still operate within the kernel networking stack, or at performance levels close to it. For most workloads, that can be enough. But for 5G UPF, trading scenarios, game servers, media servers, and other high-throughput cases, even Cilium's impressive eBPF performance may not cut it.

Notes on eBPF and DPDK

• eBPF runs inside the kernel. It's extremely fast for kernel-space operations, but it doesn't provide a true kernel bypass.
• DPDK runs in userspace. Full bypass and maximum throughput, with higher operational complexity coming along for the ride.
• In most setups, these technologies neither block nor exclude one another. Architectures using both are not hard to find.

Think of eBPF as turbocharging your existing car engine. DPDK delivers performance equivalent to swapping the engine out for a jet turbine.

DPDK + Kubernetes: Technical Integration

The Single-Interface Pod Problem

In a default scenario, every Kubernetes pod gets a single network interface. For DPDK workloads, this is a fundamental limitation. You need direct, dedicated access to a physical NIC or a virtual function, completely separate from the standard Kubernetes network path.

Multus CNI: Multiple Interfaces per Pod

Multus is a meta-CNI plugin that orchestrates multiple CNI plugins at once. With Multus, a pod can have a standard interface (eth0) for Kubernetes control plane traffic and one or more additional interfaces for DPDK-accelerated data plane traffic.

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: dpdk-network
spec:
  config: '{
    "cniVersion": "0.3.1",
    "type": "sriov",
    "name": "dpdk-network",
    "ipam": {}
  }'

NetworkAttachmentDefinition (Multus CNI)

SR-IOV: Virtual Functions for Direct NIC Access

SR-IOV (Single Root I/O Virtualization) allows a single physical NIC to be split into multiple Virtual Functions (VFs), each of which can be assigned directly to a pod:

Physical NIC (PF)
├── Virtual Function 0 → Pod A (DPDK)
├── Virtual Function 1 → Pod B (DPDK)
├── Virtual Function 2 → Pod C (DPDK)
└── Virtual Function 3 → Pod D (DPDK)
resources:
  requests:
    intel.com/intel_sriov_netdevice: '1'
  limits:
    intel.com/intel_sriov_netdevice: '1'

HugePages: The Memory Foundation

DPDK requires hugepages: large memory pages (2MB or 1GB) that reduce TLB misses during high-speed packet processing:

resources:
  requests:
    hugepages-2Mi: 512Mi
    memory: 512Mi
  limits:
    hugepages-2Mi: 512Mi
    memory: 512Mi

CPU Pinning

DPDK Poll Mode Drivers spin on dedicated CPU cores. Kubernetes manages this through the CPU Manager with a static policy:

resources:
  requests:
    cpu: '4'
  limits:
    cpu: '4'

Full DPDK Pod Manifest

apiVersion: v1
kind: Pod
metadata:
  name: dpdk-app
  annotations:
    k8s.v1.cni.cncf.io/networks: dpdk-network
spec:
  containers:
  - name: dpdk-app
    image: dpdk-app:latest
    resources:
      requests:
        cpu: '4'
        memory: 512Mi
        hugepages-2Mi: 512Mi
        intel.com/intel_sriov_dpdk: '1'
      limits:
        cpu: '4'
        memory: 512Mi
        hugepages-2Mi: 512Mi
        intel.com/intel_sriov_dpdk: '1'
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Cilium eBPF vs DPDK: Which One Should You Choose?

Hands-on: DPDK Installation and Kubernetes Integration

Prerequisites

• Linux host (Ubuntu 22.04 or RHEL 9 recommended)
• DPDK-compatible NIC (Intel X710, X550, or Mellanox ConnectX series)
• SR-IOV capable hardware with BIOS settings enabled
• Kubernetes 1.28+ cluster with CPU Manager static policy enabled
• At least 4 dedicated physical CPU cores for DPDK workloads

Step 1: System Preparation

# GRUB IOMMU activation
sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt /' /etc/default/grub
update-grub && reboot
 
# Hugepages configure
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
echo "vm.nr_hugepages=1024" >> /etc/sysctl.conf
 
# Hugepages mount
mkdir -p /dev/hugepages
mount -t hugetlbfs nodev /dev/hugepages
 
# Verify
grep HugePages /proc/meminfo

Step 2: DPDK Installation

apt-get update && apt-get install -y \
  build-essential python3-pip libnuma-dev pkg-config meson ninja-build
 
wget https://fast.dpdk.org/rel/dpdk-23.11.tar.xz
tar xf dpdk-23.11.tar.xz && cd dpdk-23.11
 
meson setup build && cd build
ninja && ninja install && ldconfig
 
# Check version
dpdk-testpmd --version

Step 3: Bind the NIC to the DPDK Driver

dpdk-devbind.py --status
dpdk-devbind.py --unbind 0000:01:00.0
modprobe vfio-pci
dpdk-devbind.py --bind=vfio-pci 0000:01:00.0

Step 4: Configure SR-IOV Virtual Functions

echo 4 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs
dpdk-devbind.py --bind=vfio-pci 0000:01:00.1
dpdk-devbind.py --bind=vfio-pci 0000:01:00.2
dpdk-devbind.py --bind=vfio-pci 0000:01:00.3
dpdk-devbind.py --bind=vfio-pci 0000:01:00.4

Step 5: Install the SR-IOV Device Plugin

kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/sriov-network-device-plugin/master/deployments/sriovdp-daemonset.yaml
 
cat <

Step 6: Install and Configure Multus CNI

kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
 
cat <

Step 7: Deploy and Test

kubectl apply -f dpdk-testpmd.yaml
kubectl logs dpdk-testpmd
# Throughput (pkts/s): TX: XXXXXXX RX: XXXXXXX

AWS and DPDK: A Pragmatic View

Running DPDK on AWS is not the same as running it on bare metal. AWS already ships its own high-performance networking layers.

Enhanced Networking and ENA

AWS instances use the Elastic Network Adapter (ENA) driver by default, which already implements several DPDK-like optimizations: up to 100 Gbps of bandwidth and consistently low latency, with no dedicated CPU core requirement.

EFA: When You Need More

For workloads that genuinely need DPDK-level performance on AWS, the answer is Elastic Fabric Adapter (EFA), available on the C5n, Hpc6a, and P4d instance families.

DPDK vs AWS EFA: Detailed Comparison

resources:
  requests:
    cpu: '4'
  limits:
    cpu: '4'

# Standard tools show nothing for DPDK traffic
tcpdump -i eth1
 
# DPDK-native packet capture tool
dpdk-pdump -- --pdump 'port=0,queue=*,rx-dev=/tmp/capture.pcap'

# CPU isolation in GRUB
GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt isolcpus=2,3,4,5 nohz_full=2,3,4,5 rcu_nocbs=2,3,4,5"