conn, tun: replace pre-made buffers with an allocator pattern

[illotum]

• 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

[nickkhyl]

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?

[nickkhyl]

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

[illotum]

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.

[nickkhyl]

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.

[illotum]

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.

[jwhited]

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

[jwhited]

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.

[jwhited]

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]

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]

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

[jwhited]

Is this sizing arbitrary?

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

[jwhited]

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:

1. they are a prerequisite for the larger packet memory architecture changes in this PR
2. they provide a modest performance improvement by collapsing memcpy/linearization into one place, kernel-side
3. they are widely supported: if sendmmsg() is supported, scatter-gather is supported through it
4. 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.