On darwin, listenIn encrypts into one SendBatch while a sender goroutine
writes the other (batch.SendPipeline). The sender takes whatever built up
during its last write, so writes overlap tun reads and packets queued
behind a write leave in one WriteBatch, which a connected socket sends as
one sendmsg_x. Two batches bound memory; a full producer waits for the
swap rather than dropping. One producer and one sender keep per-peer order
equal to message-counter order.
Everywhere else the branch is a false constant and listenIn is unchanged.
-tags send_pipeline builds the pipeline on any platform, so its tests and
the e2e suite can run through it on linux.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tun.WriteBatch writes up to 64 packets per sendmsg_x on the utun control
socket, and Passthrough.Flush hands its lane to it whole through the new
tio.BatchWriter (Caleb Jasik's #1896). Only the darwin tun implements
BatchWriter, so every other platform keeps one Write per packet.
tunQueue.Read drains every packet already queued on the utun, up to 64,
so a burst reaches the send batch together.
xnu lets only one packet wait on a utun control socket by default, so
each read found one packet. The tun now raises
UTUN_OPT_MAX_PENDING_PACKETS to 64, growing SO_RCVBUF to hold that many
packets first; on failure it logs and keeps xnu's default.
Tests: #1896's WriteBatch tests over sendmsg_x and the writev fallback,
the drain tests, the pending-packet setsockopts, and #1906's framing and
zero-alloc Read/Write tests.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
