You need packet filtering and load balancing at close to line rate on commodity Linux servers. How would you decide between an XDP/eBPF datapath and a kernel-bypass framework such as DPDK, and what does each approach cost you?

## What each one actually does **DPDK** is a bypass. You unbind the NIC from its kernel driver and bind it to a userspace I/O driver (`vfio-pci`), after which the kernel no longer knows the device exists as a network interface. A userspace poll-mode driver maps the device's queues and spins on them. Packets are delivered to your process as raw buffers, and everything above the wire — ARP, IP reassembly, TCP, routing — is your problem, either implemented by you or borrowed from a userspace stack. **XDP** is an in-kernel hook. The NIC keeps its kernel driver and remains a normal interface; your BPF program runs in the driver's receive path and returns a verdict per packet. Whatever you do not want to handle returns `XDP_PASS` and continues up the ordinary stack. That difference — total ownership versus selective interception — drives everything else. ## Performance DPDK's ceiling is higher. Nothing sits between your code and the ring, batching and prefetching are entirely under your control, and there is no per-packet kernel involvement at all. Published XDP results reach tens of millions of packets per second per core for simple programs, which is enough to saturate typical server NICs on a handful of cores; DPDK will beat that, and the gap widens as the per-packet work shrinks toward the trivial. But the shape of the cost differs as much as the size. DPDK's poll-mode driver spins: an idle DPDK core reads 100% CPU and consumes power like a busy one. XDP is driven by the ordinary NAPI mechanism, so an idle machine is idle. If your traffic is bursty or your fleet is large, that difference in the average case can outweigh the difference in the peak. ## The operational surface This is where most real decisions are made. Under DPDK the interface is gone from the kernel's point of view. `ip`, `ss`, `tcpdump`, `ethtool` statistics, netfilter, the routing table and every runbook that uses them stop applying to that NIC. Your process needs hugepages, pinned cores and, typically, exclusive hardware. Anything the kernel used to do for you — including management traffic on that link — must be re-provided, which is why DPDK deployments usually dedicate one NIC to the datapath and another to management. You have, in effect, built an appliance. Under XDP the machine stays a Linux machine. You keep SSH on the same NIC, you keep the stack for everything the program passes, and `bpftool` inspects the program and its maps live. Programs are attached and detached without restarting anything, and they are verified before they load, so a buggy program is rejected rather than crashing the kernel. The cost is real constraints. Your code must satisfy the kernel's safety checks: bounded execution, provable memory access, a limited helper set. There is no arbitrary library code, no floating point, no blocking. Complex per-packet logic is genuinely harder to express in XDP than in a userspace C program, and some of it cannot be expressed at all. ## AF_XDP as the middle road AF_XDP is worth knowing precisely because it dissolves the false dichotomy. The kernel driver stays in place; an XDP program redirects selected packets into a socket bound to a specific receive queue, and a userspace process reads them from a shared memory region, with zero copy where the driver supports it. You get userspace flexibility for the traffic you care about, the kernel stack for everything else, and no unbinding of the device. It does not match DPDK's absolute ceiling, and it introduces its own complexity, but for many "we need userspace processing of a subset of traffic" problems it is the correct answer. ## How to decide Ask what fraction of the traffic is exceptional. If nearly every packet needs custom handling and the box exists solely to do that — a router, a firewall appliance, a telco function — DPDK's ownership model matches the problem and its costs are already accepted. If most packets are ordinary and a minority need custom treatment, or the machine has another job as well, bypass forces you to reimplement the ordinary path, and XDP's selectivity is worth far more than the last increment of throughput. Then ask who operates it. XDP keeps the box debuggable with the tools your on-call already has; DPDK requires a team that owns a userspace stack, its dependencies and its own diagnostics. For filtering and L4 load balancing specifically, the program is small and uniform, most traffic is either dropped or forwarded by a fixed rule, and the industry's large deployments run in-kernel — which is a strong signal that the extra ceiling rarely justifies the extra surface.