It belongs in the kernel because 1 Gbit/s is over 80000 individual packets per second. You don't want to switch from kernel to user space and back that often. Context switches are expensive. It's a bit like reading files one byte at a time. Wireguard is designed to handle the packets with only a small amount of code in the kernel. User space code deals with the complicated things.
Intel DPDK handles ~50x more pps per core partly by running in userland instead of kernel. This is the basis of Netgate's high-throughput VPN product, TNSR [tnsr.com], and a competing (more open) project, DANOS [danosproject.org].
High-throughput VPN is an especially targeted use-case of this new type of userland networking. It's not quite normal userland like/dev/tap or BSD sockets, but I'm not sure it's really different in any fundamental or abstract way rather than simply more modern. An entire PCI device gets handed off to DPDK userland process. That's weird compared to BSD sockets, but that's not really as fundamental as it sounds. Modern network MACs are able to safely punch down a 5-tuple (src ip, src port, dst ip, dst port, tos&protocol) to a userland process, similar to direct GPU access. Though in practice what's routed to a process is usually on the scale of RDMA "verbs," single RPC calls, or the scale of whole physical ports or VLANs for userland routing or VPN, it's totally possible with the same abstractions to move TCP or IPsec or whatever into userland with a sockets-like API so only bind/listen/accept would be syscalls, not read/write.
Why in the kernel? (Score:1)
Re: (Score:1)
It belongs in the kernel because 1 Gbit/s is over 80000 individual packets per second. You don't want to switch from kernel to user space and back that often. Context switches are expensive. It's a bit like reading files one byte at a time. Wireguard is designed to handle the packets with only a small amount of code in the kernel. User space code deals with the complicated things.
Re: (Score:1)
Re:Why in the kernel? (Score:1)
Yup, "faster VPN in kernel" is an outdated bias.
Intel DPDK handles ~50x more pps per core partly by running in userland instead of kernel. This is the basis of Netgate's high-throughput VPN product, TNSR [tnsr.com], and a competing (more open) project, DANOS [danosproject.org].
High-throughput VPN is an especially targeted use-case of this new type of userland networking. It's not quite normal userland like /dev/tap or BSD sockets, but I'm not sure it's really different in any fundamental or abstract way rather than simply more modern. An entire PCI device gets handed off to DPDK userland process. That's weird compared to BSD sockets, but that's not really as fundamental as it sounds. Modern network MACs are able to safely punch down a 5-tuple (src ip, src port, dst ip, dst port, tos&protocol) to a userland process, similar to direct GPU access. Though in practice what's routed to a process is usually on the scale of RDMA "verbs," single RPC calls, or the scale of whole physical ports or VLANs for userland routing or VPN, it's totally possible with the same abstractions to move TCP or IPsec or whatever into userland with a sockets-like API so only bind/listen/accept would be syscalls, not read/write.