3 ms·

How would one circumvent the need to copy traffic between different userspace processes before it leaves the host in the case of a userspace tunnel implementati

How would one circumvent the need to copy traffic between different userspace processes before it leaves the host in the case of a userspace tunnel implementation? With a kernel implementation, the userspace process sends some data to a socket, and then the kernel can directly pass the data to the tunnel implementation with as little copying as the design for the kernel allows, and as little context switching as the design allows.

Dylan16807 5y ago
> How would do one circumvent the need to copy traffic between different userspace processes By mapping the same buffer into both processes, or moving it from one process to the other, depending on security needs. Mapping the buffer into multiple memory spaces is how a kernel VPN driver would accomplish the same thing. > as little context switching as the design allows A raw context switch only costs 20 nanoseconds for a round trip. And it's only a few more to save the normal registers. The rest is up to kernel design. So it sure sounds like it's the kernel's fault if putting tasks like that outside the kernel is too expensive. Especially since one context switch can process as many packets as you want.
- DSingularity 5y ago
  These days a lot of the context switch delays come from security mitigation’s due to vulnerable processors. Flushing TLBs. Flushing caches. Etc etc.
- zx2c4 5y ago
  Wintun -- https://www.wintun.net https://www.wintun.net -- actually uses this technique via shared memory ring buffers. And Winsock RIO has something similar for packets. We were using both of these already prior to WireGuardNT. They're fast but not conclusively so.
topspin 5y ago
"How would one circumvent the need to copy traffic" Fixing that is the point of, for example, io_uring in Linux. I don't know if Windows has an equivalent. Perhaps not, thus a kernel driver. But there is nothing mysterious about solving that problem.
- eptcyka 5y ago
  The original, canonical implementation of WireGuard on Linux predates io_during, and Windows has had IOCP for decades now.

Dylan16807 5y ago

> How would do one circumvent the need to copy traffic between different userspace processes By mapping the same buffer into both processes, or moving it from one process to the other, depending on security needs. Mapping the buffer into multiple memory spaces is how a kernel VPN driver would accomplish the same thing. > as little context switching as the design allows A raw context switch only costs 20 nanoseconds for a round trip. And it's only a few more to save the normal registers. The rest is up to kernel design. So it sure sounds like it's the kernel's fault if putting tasks like that outside the kernel is too expensive. Especially since one context switch can process as many packets as you want.

DSingularity 5y ago
These days a lot of the context switch delays come from security mitigation’s due to vulnerable processors. Flushing TLBs. Flushing caches. Etc etc.
zx2c4 5y ago
Wintun -- https://www.wintun.net https://www.wintun.net -- actually uses this technique via shared memory ring buffers. And Winsock RIO has something similar for packets. We were using both of these already prior to WireGuardNT. They're fast but not conclusively so.

topspin 5y ago

"How would one circumvent the need to copy traffic" Fixing that is the point of, for example, io_uring in Linux. I don't know if Windows has an equivalent. Perhaps not, thus a kernel driver. But there is nothing mysterious about solving that problem.

eptcyka 5y ago
The original, canonical implementation of WireGuard on Linux predates io_during, and Windows has had IOCP for decades now.