mirror of
https://github.com/tailscale/tailscale.git
synced 2026-11-08 21:16:10 +09:00
Brad Fitzpatrick
94884d27ff
A utun is a kernel control socket, and recvmsg_x and sendmsg_x work on it just as on UDP sockets. Two things prevented batching by default: xnu's utun driver queues only one packet on the control socket at a time (utun_max_pending_packets defaults to 1), so a batched read could never return more than one, and wireguard-go's Darwin tun.Device reads and writes one packet per call. Wrap the utun device in tstun.New with one that raises the queue depth via the UTUN_OPT_MAX_PENDING_PACKETS socket option and reads and writes batches of up to 128 packets through net/msgx, when msgx is available. Any unexpected error disables the batched path for the life of the device and falls back to the wrapped one. With this, the kernel's TCP stack fills the utun queue under load, wireguard-go encrypts batches, and the connected per-peer sockets send them with one sendmsg_x each. Measured between two M5 Pro Mac minis on a 10 Gbps LAN (iperf3 over Tailscale, 10 second runs, tailscaled CPU seconds per side): before (connected sockets + msgx, per-packet utun) 1.45 Gbps 24.5s / 9.3s with batched utun 4.85 Gbps 25.4s / 25.5s No retransmits in any run. The sender profile is now 19% crypto and most of the rest kernel time in sendmsg_x doing real work; scheduler churn drops from about half of CPU to about a fifth. TS_DEBUG_TUN_BATCH=0 disables it for evaluation. Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com> Change-Id: I2c7e5a9f1b4d8306e7a2c9d5f1b3e8a6c4d7f2b1