Kernel‑bypass stacks moving to production

Most network software still takes the long route: a packet lands on a network card, climbs through the Linux kernel, gets copied into an app, and only then gets parsed. Every handoff costs time, and those costs pile up when a search or trading system is serving many clients at once. (docs.kernel.org) Address Family Express Data Path, usually called Address Family XDP, is a shortcut lane inside Linux. An Express Data Path program can grab packets at the driver level and redirect them into a user-space socket, skipping most of the normal kernel network stack. (docs.kernel.org, docs.ebpf.io) That user-space socket works through shared rings, which are just circular inboxes for packet ownership. Linux documents four of them for Address Family XDP: receive, transmit, fill, and completion, all pointing at a shared memory region called user memory. (docs.kernel.org, docs.ebpf.io) Zero-copy is the next piece. In Linux terms, zero-copy receive means packet data can land directly in application memory instead of being copied again from kernel memory into a process buffer. (docs.kernel.org) Input output uring, written as io_uring, is Linux’s newer asynchronous input and output interface built around shared rings between user space and the kernel. The kernel manual says it can avoid buffer-copy overhead where possible, and its zero-copy receive path is now documented as a first-class networking feature. (man7.org, docs.kernel.org) The reason engineers care is simple: if your app stops asking the kernel to touch every packet twice, one core can do more useful work. The Linux kernel documentation for io_uring zero-copy receive says the feature exists specifically to remove the kernel-to-user copy on the network receive path. (docs.kernel.org) That is why the recent engineer reports are getting attention. The claim is not a lab benchmark on synthetic traffic, but production use of Address Family XDP, io_uring, and zero-copy decoding to keep tail latency under 25 milliseconds at the 99th percentile on multi-client search and execution workloads. (x.com) There is a second thread running alongside the latency story. Extended Berkeley Packet Filter, or eBPF, lets developers load sandboxed programs into the Linux kernel, and Red Hat’s documentation lists packet filtering, traffic monitoring, and control-group-based socket filtering among the networking features already built on it. (ebpf.io, docs.redhat.com, docs.ebpf.io) Control groups are Linux’s way of putting a set of processes in one box. eBPF programs attached to a control group can filter packets for the processes inside that box, which is the building block behind per-process or per-service firewall behavior instead of one giant host-wide rule list. (docs.redhat.com, docs.ebpf.io) That is what makes the new Linux firewall demos interesting. They are trying to give Linux the kind of application-level network controls Mac users know from app firewalls, but with eBPF hooks that run close to the packet path and add less overhead than older rule chains. (x.com, docs.ebpf.io) The final clue that this is moving out of the demo phase is where kernel work is heading next. A March 27, 2026 netkit patch series from Daniel Borkmann adds queue leasing so containers can use io_uring zero-copy and Address Family XDP against physical network queues at native speed, with tests on 100 gigabit Nvidia ConnectX-6 and Broadcom BCM957504 cards. (lwn.net) Put together, these pieces describe a new split in Linux networking. More of the fast path is moving either into user space through kernel bypass or into tiny kernel-resident programs through eBPF, and both approaches are now showing up in production reports instead of conference slides. (docs.ebpf.io, ebpf.io, lwn.net)