Wireguard in kernel gives great performance while just working if your kernel is already working on the hardware. Wireguard is so small it is considered easy to audit so is a prime candidate for kernel implementation.
DPDK is listed as an "Exotic" todo for Wireguard:
1. It is faster if you make it so, i.e., you need to invest quite some work to get to a point where it's faster than kernel - but yea, with that you can make it go brrrrrrrt in quite a few use cases, it's more like an SDK.
2. Some NICs support loading a smaller program to operate directly on the NIC, e.g., through eBPF - nothing gets faster than that as it avoids that (some) traffic hits the CPU at all. But again, it's work to create and maintain and only feasible for specialized stuff.
3. Note that with Linux[0] a lot of the context switch overhead can be avoided by leveraging the state of the art async framework IO-uring, BSD may already have or get something similarily[0]. I recommend reading the paper of the original author[0], it's fascinating IMO.
[0]: I know this is about BSD, so somewhat off-topic, but still shows that most of the context switch complexity can be avoided while not re-inventing the wheels in user-space.
TCP is a beast with opportunity for countless subtle bugs. The Linux kernel is perhaps the best implementation there is. Many userspace implementations are simplified and missing features.
Even giants like Cloudflare use Linux kernel for routing when they need to operate above layer 3. They only use DPDK for very low level features.
DPDK has its place but for most use cases you need to man handle TCP and you're better off using kernel packet handling for that
What could you possibly mean by this?
Their line rate stuff for flood mitigation uses DPDK or similar
The Wireguard implementation in VPP runs at about 5Gbps in a simple single-stream iperf test.
Kernel Wireguard is almost 3gbps.
But Wireguard is mostly held back by the slow crypto implementation, which is CPU-bound.
AES-GCM IPsec on the same hardware is 19.5gbps, limited by the 25gbps NIC, using again, single-stream iperf with ipsec in VPP.
DPDK only needs dedicated cores for the poll mode drivers, and these days the Intel and mellanox NICs can be run in interrupt mode.
Good numbers either way, but you again much more limited hardware support since the drivers need to be DPDK specific.
But Wireguard is still crypto-limited, the AES-GCM result proves it.
Also looks like AF_PACKET and AF_XDP are basically an alternative to DPDK with similar functionality but built into the kernel using kernel drivers, new to me.