user-space networking and kernel-bypass (DPDK)
/ DPDK -> dee-pee-dee-KAY /
Normally every network packet your program sends or receives passes through the operating-system kernel, which copies it, runs the TCP/IP stack, manages interrupts, and switches between user and kernel mode. That is convenient and safe, but each of those steps costs CPU, and at tens of millions of packets per second the kernel itself becomes the bottleneck. Kernel-bypass networking takes a radical step: let the application talk to the network card almost directly, doing the networking in user space and leaving the kernel out of the fast path.
How it works in broad strokes: a framework like DPDK (the Data Plane Development Kit) binds a network interface to a special user-space driver, maps the card's packet buffers directly into your process's address space, and lets you read and write packets without system calls or kernel copies. Instead of waiting for interrupts, a dedicated CPU core POLLS the card in a tight loop (busy-waiting), so packets are picked up the instant they land with no interrupt latency. Because the kernel's TCP/IP stack is bypassed, you either run a user-space TCP stack on top or handle raw packets yourself. Related kernel features like XDP let you run small programs at the earliest point in the kernel's receive path for similar speedups without fully leaving the kernel.
Why it matters: kernel-bypass is how the most demanding systems - high-frequency trading, software routers, telecom data planes, top-tier load balancers - reach the C10M scale and microsecond latencies the general-purpose kernel path cannot. The honest caveats are steep: you dedicate whole CPU cores to busy-polling (burning 100% even when idle), you lose the kernel's mature, secure, battle-tested TCP/IP stack and tooling, the card is monopolised by one application, and the code is far harder to write and operate. It is a specialist tool, not a default - most servers should use epoll/io_uring and keep the kernel.
/* DPDK fast path, sketch */ while (running) { uint16_t n = rte_eth_rx_burst(port, 0, bufs, BURST); for (uint16_t i = 0; i < n; i++) process(bufs[i]); } /* a core busy-polls the NIC, no syscalls, no interrupts */
A dedicated core spins polling the NIC and processes packet bursts directly in user space - no kernel in the loop.
Kernel-bypass trades away the kernel's safety, security, and mature TCP/IP stack for raw speed, and busy-polling burns a full core continuously. It is a niche tool for extreme packet rates; for ordinary high-performance servers, epoll/kqueue/io_uring with the kernel stack is the right choice.