KNOD
KNOD — in-kernel network offload device — is a Linux kernel patch series that runs network packet processing on an AMD GPU instead of the CPU. It was posted as an RFC to the kernel mailing list; as of 2026-07-22 there is no target release for merging it (knod-igorslab).
How it works
The NIC writes received packets “directly into GPU memory via DMA”, and the GPU then works on many packets at once. The unusual part is who drives the GPU: “the Linux kernel itself manages the GPU queues, compiles the programs via JIT into suitable GPU machine code, and then initiates their processing” (knod-igorslab). Three things are proposed as offload targets — XDP programs, IPsec Security Associations, and load-balancing/filtering.
That JIT step is the same move ebpf makes (bytecode verified, then JIT-compiled to native speed), only the native target is a GPU instruction set rather than the host CPU’s. Where sched-ext took ebpf‘s in-kernel-programmability thesis sideways into the scheduler, KNOD takes it off the processor: the program is still loaded and managed by the kernel, but it no longer executes there.
No ROCm in the data path
Normally, using a GPU for compute means a userspace runtime — AMD’s ROCm, or CUDA. KNOD’s stated design is that “a userspace runtime such as AMD ROCm or CUDA is not intended to be a permanent part of the data path” (knod-igorslab). The kernel talks to the GPU itself. This is only tractable on AMD because its Linux graphics driver already lives in the mainline kernel as open source; testing is reported on GCN and RDNA2 parts.
Read against this spoke’s seams thesis, it cuts one seam and opens another. Out goes the kernel↔userspace-runtime boundary on the hot path (a version-matched vendor stack that fleet operators otherwise have to keep current); in comes a kernel↔GPU boundary, with the packet’s fate now depending on a driver and a JIT that the networking stack does not own.
What is not yet known
The reporting carries no latency, throughput, or CPU-savings figures (knod-igorslab). That is the number the whole idea rests on: per-packet work on a GPU pays a PCIe hop and a dispatch cost that a CPU running XDP at the driver hook does not. Nothing is said about kernel-developer reception either, and an RFC is where that gets decided.
Cross-spoke context
The wider “get packet processing off the host CPU” idea also shows up as DPUs / SmartNICs — NVIDIA’s
BlueField + DOCA line, parked in the hub _inbox under ai-infrastructure. That approach adds dedicated
silicon; KNOD reuses a GPU the machine may already have and keeps the control plane in the kernel. Same
goal, different bet on hardware.