conn, tun: replace pre-made buffers with an allocator pattern by illotum · Pull Request #49 · tailscale/wireguard-go

illotum · 2026-02-19T04:43:01Z

Replace fixed 65 KB buffers per-buffer allocations with a tiered sync.Pool
Push buffer allocation to the edge: tun.Read and conn.ReceiveFunc accept nil buffer entries and allocate on demand
Each buffer carries a recycle function routing it back to its origin pool
TX coalescing (coalesceMessages) uses scatter-gather instead of copying into a contiguous slice
GRO coalescing uses a bump-pointer Arena for temporary scratch buffers

Reduces resident memory by an order of magnitude & improves (best case, iperf) throughput by about 10%.

Updates tailscale/corp#36989

Change-Id: I1a72cd54d4be2b3b0c7568982e1a700c6a6a6964

buffer/buffer.go

nickkhyl · 2026-03-12T17:05:53Z

buffer/buffer.go

+// The returned Data slice must not be retained past Release.
+type Buffer struct {
+	data    []byte
+	recycle func(*Buffer)


Currently, recycle is always nil.

I'd expect that different buffer.Source implementations would want to use different recycle implementations (e.g., tsvnic vs rioconn vs sync.Pool).

What's the plan here?

Currently, buffer.FragmentPool sets the unexported recycle field directly, but external packages won't be able to do that, so I'm wondering what the API surface should look like.

Or is the expectation that all allocators be implemented in this package? We can explore that for rioconn, but perhaps not for tsvnic. This is what we currently have for rioconn: https://github.com/tailscale/tailscale/blob/nickkhyl/rioconn/net/rioconn/request_ring.go

Do either of them need more than uint64 of metadata? Per my original message, I considered just packing a metadata field into every buffer. And yes, making them all public.

If we need more, interfaces become an appealing option.

yeah, I'd expect uint64 (or perhaps even uintptr) to be sufficient.

We can iterate on the specifics later, since it seems we're on the same page about the API, and there's also no expectation that all implementations should live in wireguard-go/buffer.

After some deliberation, I opted to instead embed an interface -- I/O implementations may stuff it with arbitrary data as needed. LMK what you think.

buffer/buffer.go

jwhited · 2026-03-18T17:28:26Z

buffer/buffer.go

+package buffer
+
+const (
+	MaxMessageSize = (1 << 16) - 1 // largest possible UDP datagram


does this relate to a similar constant defined in device/queueconstants*, or should it be independent?

jwhited · 2026-03-18T17:34:45Z

tun/tun_windows.go

 		switch err {
 		case nil:
+			if bufs[0] == nil {
+				bufs[0] = buffer.New(make([]byte, buffer.MaxMessageSize), nil)


Related to https://github.com/tailscale/wireguard-go/pull/49/changes#r2955084809

This would have previously been sized to 2016 bytes. Other platforms vary as well, e.g. android, iOS.

buffer/buffer.go

jwhited · 2026-03-18T17:51:35Z

I ran some local, single TCP stream benchmarks w/iperf3 on Ubuntu 24.04 w/Intel i5-12400 CPUs.

4184faf (what's currently used by tailscale/tailscale):

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  14.9 GBytes  12.8 Gbits/sec  604             sender
[  5]   0.00-10.00  sec  14.9 GBytes  12.8 Gbits/sec                  receiver

472f369:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  12.2 GBytes  10.5 Gbits/sec  291             sender
[  5]   0.00-10.00  sec  12.2 GBytes  10.5 Gbits/sec                  receiver

RSS is much improved w/lots of streams (-P 32): 1GB+ vs ~200MB

jwhited · 2026-03-18T20:03:14Z

device/device.go

-		messageBuffers            *WaitPool
 		inboundElements           *WaitPool
 		outboundElements          *WaitPool
+		messageBuffers            buffer.Source


reminder: We will need to support a limit, e.g. PreallocatedBuffersPerPool constant today, on the outstanding buffers or outstanding aggregate buffer size for mobile platforms , which WaitPool previously enforced with its max field set to nonzero value.

jwhited · 2026-03-18T20:11:08Z

device/send.go


-	err = peer.SendBuffers([][]byte{buf})
+	err = peer.SendBuffers([][]byte{buf.Data()})
+	buf.Release()


Can we defer release immediately following instantiation? Same with all the other handshake and initiation message sending methods.

jwhited · 2026-03-18T20:16:19Z

tun/tun_linux.go

 	}
 	file := os.NewFile(uintptr(fd), "/dev/tun")
+	bufPool := buffer.NoErrSource{Source: buffer.NewDefaultFragmentPool()}
+	arenaBuffer, _ := bufPool.Get(32 * 16 << 10)


Is this sizing arbitrary?

Can we document the decimal value in human-readable form?

jwhited · 2026-03-18T20:31:30Z

conn/bind_std.go


 type setGSOFunc func(control *[]byte, gsoSize uint16)

 func coalesceMessages(addr *net.UDPAddr, ep *StdNetEndpoint, bufs [][]byte, offset int, msgs []ipv6.Message, setGSO setGSOFunc) int {


I would love to see the scatter-gather changes land in tailscale/tailscale (net/batching pkg) before larger tailscale/wireguard-go changes.

My understanding is that:

they are a prerequisite for the larger packet memory architecture changes in this PR

they provide a modest performance improvement by collapsing memcpy/linearization into one place, kernel-side

they are widely supported: if sendmmsg() is supported, scatter-gather is supported through it

they also benefit peer relay, which uses net/batching

While I don't anticipate any issues with the approach, it would be better (and easier) to identify kernel bugs or whatever early and detached from the larger changes here.

On Linux NativeTun will write a vector of coalesced buffers via writev(2) instead of copying fragments into a single buffer. Updates tailscale/corp#36989 Signed-off-by: Alex Valiushko <alexvaliushko@tailscale.com> Change-Id: Id1e9cd3cc9435c240b7a28ae6528cd7e6a6a6964

Signed-off-by: Alex Valiushko <alexvaliushko@tailscale.com> Change-Id: I58908d9d3fd09441e9378a74b0ee19136a6a6964

illotum force-pushed the illotum/rss-optimization branch 9 times, most recently from 496dc1a to 61b6c72 Compare March 8, 2026 03:43

illotum self-assigned this Mar 9, 2026

illotum force-pushed the illotum/rss-optimization branch 4 times, most recently from ea6f82a to e981b07 Compare March 12, 2026 03:37

raggi reviewed Mar 12, 2026

View reviewed changes

buffer/buffer.go Outdated Show resolved Hide resolved

nickkhyl reviewed Mar 12, 2026

View reviewed changes

buffer/buffer.go Outdated Show resolved Hide resolved

jwhited reviewed Mar 18, 2026

View reviewed changes

buffer/buffer.go Outdated Show resolved Hide resolved

jwhited reviewed Mar 18, 2026

View reviewed changes

buffer/buffer.go Outdated Show resolved Hide resolved

jwhited reviewed Mar 18, 2026

View reviewed changes

illotum force-pushed the illotum/rss-optimization branch from 472f369 to 74691ad Compare March 18, 2026 22:18

illotum force-pushed the illotum/rss-optimization branch 2 times, most recently from d7467f5 to f357c5a Compare March 26, 2026 23:41

illotum force-pushed the illotum/rss-optimization branch 3 times, most recently from 20d395d to e016f9e Compare April 9, 2026 02:10

illotum added 2 commits April 9, 2026 10:33

tun, device: allocate buffers in the edge devices

14a0542

Signed-off-by: Alex Valiushko <alexvaliushko@tailscale.com> Change-Id: I58908d9d3fd09441e9378a74b0ee19136a6a6964

tun, conn: save memory during allocation

5c07b88

Signed-off-by: Alex Valiushko <alexvaliushko@tailscale.com> Change-Id: I58908d9d3fd09441e9378a74b0ee19136a6a6964

illotum force-pushed the illotum/rss-optimization branch from e016f9e to 5c07b88 Compare April 9, 2026 17:34


		type setGSOFunc func(control *[]byte, gsoSize uint16)

		func coalesceMessages(addr net.UDPAddr, ep StdNetEndpoint, bufs [][]byte, offset int, msgs []ipv6.Message, setGSO setGSOFunc) int {

Conversation

illotum commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jwhited commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

illotum commented Feb 19, 2026 •

edited

Loading

jwhited commented Mar 18, 2026 •

edited

Loading