"Fine, I'll Do It Myself."
For years, the dominant solution to the kernel bottleneck was DPDK (Data Plane Development Kit), an open-source framework originally developed by Intel. DPDK's philosophy is radical: if the kernel is too slow, remove it from the equation entirely.
DPDK works by having the application take exclusive, direct control of the Network Interface Card (NIC). Instead of the kernel managing the NIC, the DPDK application loads its own Poll Mode Driver (PMD) — a user-space driver that talks directly to the NIC hardware. The application then runs a tight polling loop, continuously checking the NIC's receive ring for new packets without any interrupt overhead. No system calls. No context switches. No sk_buff. Just raw memory mapped directly from the NIC into the application's address space.
This approach is genuinely fast. DPDK can process tens of millions of packets per second on commodity hardware. It's used in telecom infrastructure, high-frequency trading networks, and carrier-grade NAT appliances.
The Problems with DPDK:
-
Exclusive Ownership: Once your application claims a NIC via DPDK, that interface is invisible to the Linux kernel. You cannot SSH into it. You cannot run
tcpdumpon it.ip addrwon't show it. It's a black box that only your application can see. -
You Must Rebuild Everything: Because the kernel's networking stack is bypassed, you must reimplement ARP, TCP/IP, DNS, and any other protocol your application needs — entirely in user space. Projects like DPDK's own
librte_netand third-party stacks likemTCPexist for this, but the complexity is enormous. -
Security Risk: A bug in a DPDK application can corrupt NIC hardware state, cause kernel panics, or expose raw memory. Because it runs with ring-0 equivalent access to hardware, there is no safety net.
-
Operational Isolation: Standard Linux monitoring, observability, and security tooling simply doesn't work on DPDK interfaces. You're flying blind unless you build your own telemetry.