ACE Journal

WireGuard Kernel Offload and the State of Hardware Acceleration

Abstract

WireGuard’s minimal codebase and modern cryptography (ChaCha20-Poly1305, Curve25519) made it a compelling replacement for IPsec and OpenVPN when it merged into the Linux kernel in 5.6. But WireGuard’s CPU-bound encryption has become a bottleneck as link speeds climb to 100GbE and beyond in data center and cloud gateway contexts. The kernel’s crypto offload infrastructure, combined with emerging NIC-side WireGuard acceleration, is beginning to address this - but the story is more fragmented than the simple “hardware fixes it” narrative suggests.

Kernel Crypto Offload Foundations

The Linux kernel’s crypto API supports hardware acceleration transparently: AES-NI on x86, NEON on ARM, and vendor-specific engines exposed via drivers. For WireGuard specifically, ChaCha20-Poly1305 acceleration via AVX-512 on recent Intel and AMD CPUs already yields substantial improvements over scalar implementations - on a single Xeon core, AVX-512 ChaCha20 can sustain throughput that makes CPU saturation irrelevant at 10GbE. The picture changes at 100GbE, where a single gateway core cannot keep pace with line-rate encryption even with SIMD. The kernel’s net/wireguard implementation uses per-CPU worker queues, spreading encryption work across available cores, but this introduces packet reordering complexity and context-switch overhead at high connection counts.

NIC-Side Offload - Where Things Stand

True NIC offload - moving ChaCha20-Poly1305 encryption onto the NIC ASIC - is not yet standardized. Netronome (now part of Corigine) demonstrated WireGuard offload on their Agilio NFP line, and there is experimental support in the kernel’s crypto subsystem via the xfrm offload path, though WireGuard does not use xfrm natively. Several efforts exist to bridge this gap: the wireguard-go userspace implementation can route through DPDK-backed crypto libraries for high-throughput gateway deployments, sacrificing kernel integration for throughput. Cloudflare’s Boringtun, their Rust userspace WireGuard implementation, takes a similar approach, trading kernel integration for per-core scaling that works well in their anycast gateway architecture.

The Path Forward

The most promising near-term direction is hybrid offload: control-plane and key exchange remain in the kernel, while data-plane encryption migrates to a co-processor or SmartNIC via an eBPF-based shim. Intel’s IPU (Infrastructure Processing Unit) line and NVIDIA’s BlueField-3 DPUs both expose crypto acceleration accessible via kernel bypass paths. Projects like Cilium have demonstrated eBPF-based WireGuard-like datapaths that can push encryption onto DPU hardware while maintaining Linux netfilter compatibility. This is not a drop-in WireGuard replacement, but for operators building new gateways at 100GbE and above, it is the realistic high-throughput path until in-kernel NIC offload standardization matures.

Practical Guidance

For operators today, the most impactful tuning steps remain CPU-side: pinning WireGuard’s worker threads to isolated cores via cgroups, enabling CONFIG_CRYPTO_CHACHA20_X86_64 and verifying it is active via /proc/crypto, and sizing gateway instances with enough physical cores to sustain target throughput before chasing NIC offload solutions that remain deployment-specific.