KNOD Wants to Turn Your AMD GPU Into a DPU

The Linux kernel has JIT-compiled packet-processing programs for years — that's what eBPF does on your CPU. A new RFC patch series called knod ("kernel network offload device"), posted to the kernel mailing list by netdev contributor Taehee Yoo on July 19, asks a more audacious question: why not JIT that program to GPU machine code and let a Radeon chew through packets instead?

The cover letter describes the flow plainly: the NIC DMAs received packets directly into GPU memory, the GPU runs the program across a batch of packets in parallel, and only the results come back — a verdict for every packet, plus the packet itself for the ones destined to the host. Development happened on AMD GCN (Radeon RX Vega) and RDNA2 hardware, and it's the AMD focus that makes the whole thing possible.

GPU packet processing is old. This part isn't.

Running network workloads on GPUs is a fifteen-year-old idea — PacketShader was pushing tens of gigabits through GPUs as a software router back in 2010. The modern incarnations are DPDK's gpudev library and NVIDIA's DOCA GPUNetIO, which let DPDK applications land packets in GPU memory and process them with CUDA kernels.

Every one of those designs shares a structural assumption: a userspace GPU runtime sits in the data path. CUDA or ROCm allocates the memory, compiles the kernels, manages the queues. Your packet pipeline is welded to a multi-gigabyte, fast-moving userspace SDK, and the OS kernel is a bystander.

knod inverts that. The kernel itself builds the GPU queues, JIT-compiles the per-packet program to GPU ISA, and dispatches the work — no ROCm, no userspace runtime, nothing outside the kernel touching the hardware. Conceptually it's the eBPF JIT story replayed with a much stranger backend: instead of emitting x86 or arm64, the kernel emits GCN or RDNA2 instructions.

That's also why this is an AMD story rather than a generic GPU story. Driving a GPU's rings and compiling to its ISA from kernel space requires a fully documented, fully upstream driver stack, which amdgpu uniquely has. NVIDIA's architecture keeps too much behind the proprietary runtime for an upstream kernel to drive it this way; Intel is theoretically possible but nobody's written it. AMD spent a decade eating the cost of upstream-first driver development, and knod is the kind of dividend that strategy occasionally pays: someone outside the company can propose making your GPUs do an entirely new job, in mainline, without asking permission.

What you'd actually offload

The RFC targets two concrete consumers: XDP programs and IPsec Security Associations.

Both are workloads where per-packet CPU budget is the wall. At 100GbE line rate with small packets you're staring down ~148 million packets per second; even spread across many cores, that leaves a few hundred nanoseconds per packet before you're dropping. Simple XDP programs — parse, match, drop — fit fine. Compute-heavy ones — stateful DDoS scoring, non-trivial classification, anything cryptographic — don't, which is why XDP has a hardware-offload mode that in practice only ever worked on Netronome's SmartNICs. IPsec is the same shape: you either burn cores on AES or buy one of the short list of NICs with inline crypto offload. A GPU running the same operation across thousands of packets in lockstep is a genuinely good architectural fit for both, and knod would expose it through kernel interfaces you already use rather than a vendor SDK.

The trade-offs are equally concrete. GPUs earn their throughput through batching, and batching costs latency — if your p99 matters more than your packets-per-second, a design that queues packets for parallel dispatch is working against you. Host-destined traffic pays a PCIe round trip. And the "offload to the GPU" pitch reads differently depending on whose GPU: dedicating a $200 previous-generation Radeon as a packet engine in a firewall or load balancer is an interesting build; stealing occupancy from accelerators you bought for training is not. Despite the framing that's floated around this story, knod is not about speeding up AI-cluster traffic — that problem belongs to RDMA and the devmem TCP work already upstream, which move payload bytes without the CPU touching them. knod is about computing on packets, and its natural competitor isn't GPUDirect; it's the DPU. A BlueField-class card is, reductively, a NIC plus a computer that runs your packet programs. knod proposes the computer you already have.

Between an RFC and your racks

Now the cold water. The cover letter ships no performance numbers — for a patch series whose entire justification is efficiency, that's the first thing the netdev maintainers will ask for, and until figures appear the throughput story is a plausible hypothesis, not a result. The series is an RFC with no target release, sitting across two of the kernel's most demanding subsystems (netdev and DRM). And its boldest feature is also its scariest: an in-kernel compiler targeting GPU ISAs is a substantial new attack and maintenance surface, one that needs a new backend for every GPU generation and an answer for what happens to in-flight packets when the GPU resets. Yoo has been socializing the idea since Linux Plumbers Conference 2025, which is the right way to land something this invasive — and also a signal that even the author expects a multi-year path.

My read: this is the real thing, not hype — a genuinely novel architecture that only became possible because AMD's driver stack is fully upstream — but it's at the beginning of a long negotiation with reality. If you run compute-heavy XDP or terminate serious IPsec volume, the thread is worth following closely, because a standard kernel API for GPU packet offload would let you shop for cheap parallel silicon instead of specialty SmartNICs. Just don't sketch any architecture diagrams with knod in them yet. The right verb for 2026 is watch.