The New Challenger: XDP (eXpress Data Path)

The Best of Both Worlds

Linux engineers asked a precise question: "What if we could process packets at near-DPDK speeds, but without abandoning the kernel and all the tools that depend on it?"

The answer, merged into the Linux kernel in version 4.8 (2016), is XDP (eXpress Data Path).

XDP allows you to attach a small, sandboxed program — written in a restricted subset of C and compiled to eBPF (extended Berkeley Packet Filter) bytecode — directly into the network driver, at the earliest possible point in the software stack. This hook fires immediately after the packet arrives from the wire, before the kernel allocates the sk_buff structure.

The XDP Hook Position:

NIC Hardware
     ↓
NIC Driver (Ring Buffer)
     ↓
[XDP HOOK — Your program runs HERE]
     ↓  (only if XDP_PASS is returned)
sk_buff allocation
     ↓
Full Kernel Networking Stack
     ↓
User-space Application

Because the XDP program executes before the expensive sk_buff allocation, it avoids the primary source of kernel networking overhead. The program operates directly on the raw packet memory in the NIC's DMA ring buffer — the same memory the hardware wrote into. No copies. No allocations. Just a pointer to raw bytes and a decision to make.

XDP programs are loaded into the kernel using the bpf() system call and verified by the eBPF verifier — a static analysis engine that proves the program is safe before it runs. This is the critical difference from DPDK: your code runs inside the kernel, but it cannot crash it.

Three XDP Operating Modes:

For production use, Native XDP is the target. Most modern NIC drivers (mlx5, i40e, ixgbe, virtio) implement the XDP hook. Generic XDP is invaluable for development — you can test your XDP program on a standard VM without special hardware.