2 ms·

GSO (Generic segmentation offload) is supported for UDP in the Linux kernel from 4.18 so I would assume these optimizations should be easily possible for the ke

GSO (Generic segmentation offload) is supported for UDP in the Linux kernel from 4.18 so I would assume these optimizations should be easily possible for the kernel driver as well and can take advantage of any drivers that pass the GSO down to the network hardware too. Kinda weird optimization though; I'm not exactly sure why it works as well as it appears to; I am thinking that the gain may be far far less noticeable/important at <1gbps. This may be why there aren't any benchmarks for lower end devices or bandwidth constrained paths. On another front, I wonder would there be any advantage to encapsulating a native UDP protocol like wireguard in QUIC frames? Might this result in increased reliability and improved packet handling from firewalls and middleboxes?

dan-robertson 3y ago
Wireguard udp packets are already pretty unstructured. The first four bytes are 4, 0, 0, 0. They have another 12 bytes of header and then encrypted data.
stock_toaster 3y ago
> GSO down to the network hardware too Isn't the article specifically talking about tx-udp-segmentation in the tun driver though, and not the hardware nic adapter? From the article: > The TUN driver support in v6.2 was the missing piece > needed to improve UDP throughput over wireguard-go. With > it toggled on, wireguard-go can receive “monster” UDP > datagrams from the kernel
tomohawk 3y ago
GSO improves performance because you can send a ~64kB "datagram" through the stack, and then it will be split up either by the network card (if it supports GSO) or by the kernel. This is a lot more efficient than sending a pile of 1500 byte packets through the stack. It also saves a lot of context switches with the kernel. By way of comparison, when you send data over TCP, the system call interface lets you write very large chunks, so a single system call can write gigabytes of data.

dan-robertson 3y ago

Wireguard udp packets are already pretty unstructured. The first four bytes are 4, 0, 0, 0. They have another 12 bytes of header and then encrypted data.

stock_toaster 3y ago

> GSO down to the network hardware too Isn't the article specifically talking about tx-udp-segmentation in the tun driver though, and not the hardware nic adapter? From the article: > The TUN driver support in v6.2 was the missing piece > needed to improve UDP throughput over wireguard-go. With > it toggled on, wireguard-go can receive “monster” UDP > datagrams from the kernel

tomohawk 3y ago

GSO improves performance because you can send a ~64kB "datagram" through the stack, and then it will be split up either by the network card (if it supports GSO) or by the kernel. This is a lot more efficient than sending a pile of 1500 byte packets through the stack. It also saves a lot of context switches with the kernel. By way of comparison, when you send data over TCP, the system call interface lets you write very large chunks, so a single system call can write gigabytes of data.