The in-kernel offload project skips ROCm and CUDA entirely, and its developers brought fresh numbers to Linux Plumbers in Prague.
A graphics card in a server usually earns its keep running AI models or rendering frames. KNOD wants it to do something far less glamorous: chew through network packets on behalf of the Linux kernel. The project, short for “in-kernel network offload device,” got a progress update at this week’s Linux Plumbers Conference in Prague, and the headline numbers are up to 70 million packets per second on an XDP workload and 80 Gbit/s of IPsec on the receive side, measured on consumer AMD GPUs.
The talk was given by Hoyeon Lee of SUSE and Taehee Yoo of LINE Investment Technologies in the conference’s networking track, according to the LPC session page, and Phoronix has posted the key slides.
The mechanism is surprisingly direct. The kernel takes an XDP program, the small packet-handling programs Linux already uses for firewalls, DDoS scrubbing and load balancing, and JIT-compiles it into GPU machine code. The network card drops incoming packets straight into memory the GPU can reach, the GPU runs the program across a large batch of them in parallel, and it hands back the usual XDP verdicts: pass, drop, redirect. The 70 Mpps figure comes from a workload derived from Katran, Meta’s open-source XDP load balancer, so this is not a synthetic loop that leaves packets untouched.
No ROCm, no CUDA, no userspace #
What makes KNOD unusual is where it lives. GPU packet processing is not a new idea, and academic projects have toyed with it for well over a decade, but almost all of them route data through a userspace runtime. KNOD keeps CUDA, ROCm and any userspace component out of the data path altogether. The kernel manages the GPU queues itself and leans on AMD’s open-source amdgpu driver, which already ships in mainline. That is the whole reason Radeon came first.
The prototype shown at LPC 2025 simply ran XDP on an AMD GPU from inside the kernel. Since then the developers have redesigned the NIC-to-GPU path, added support for divergent control flow (branches that send different packets down different code paths, something GPUs traditionally hate), brought up RDNA2 alongside the older GCN parts, and tuned batching, dispatch, occupancy and memory transfers. RX IPsec arrived as a second use case, which turns the project from a clever XDP trick into a more general offload-device model.
The pitch is economics. Saturating a fast link with XDP on CPU cores alone eats a lot of those cores, while SmartNICs and DPUs are expensive and vendor-specific. A cheap consumer GPU that costs a fraction of a DPU, or is already sitting in the box, is a tempting alternative. The developers argue KNOD is both cheaper and more power-efficient than CPU-only processing, but the cost and power comparisons were shown as charts rather than published figures, so treat them as the project’s own claims for now.
Still an RFC #
None of this is in the kernel yet. KNOD was posted as an RFC patch series in July, as Igor’s Lab noted at the time, and the list of open questions is long: where the boundaries sit between the networking core, BPF, DRM and accelerator drivers, how per-CPU maps and queue affinity should behave on a device that is not a CPU, and what the Generic Netlink control plane should look like. Arguments like those can take several kernel cycles to settle, especially with maintainers from four subsystems at the table.
The hardware list should grow, too. The to-do slide shown in Prague includes Intel Arc graphics and AMD integrated GPUs, not just discrete Radeons, and on the network side KNOD already works with Broadcom and Intel adapters. If integrated graphics support lands, the pitch shifts from “add a cheap GPU” to “put the idle iGPU on your APU to work,” which is a much easier sell.
For now, KNOD is a neat proof that the GPU in a Linux box can be treated as just another kernel-managed accelerator rather than an island with its own software stack. Whether the netdev maintainers agree to let it in is the next, and harder, test.