perf(windows): batch Wintun reads and RIO sends#138
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
This PR improves the Windows data-plane by enabling packet batching in the Wintun receive path and batching RIO sends under fewer locks/commits, with a new 32-packet batch limit intended to improve throughput (especially for small packets) without regressing latency.
Changes:
- Implement bounded Wintun receive batching and advertise a Windows TUN batch size of 32.
- Batch WinRIO transmits: reserve ring capacity for the whole batch, defer multi-packet sends, and commit once per batch while keeping a single-packet fast path.
- Add Windows-specific unit tests for RIO send flag selection and ring-buffer accounting helpers.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| polyamide/tun/tun_windows.go | Introduces Wintun receive batching and increases the advertised TUN batch size to 32. |
| polyamide/conn/bind_windows.go | Adds ring capacity helpers and refactors WinRIO send to support deferred multi-packet batches with a single commit. |
| polyamide/conn/bind_windows_test.go | Adds unit tests for rioSendFlags and ring-buffer helper methods used by the new batching logic. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
Author
|
The failed e2e test just seems to be test flakiness |
Owner
|
This change looks good, thank you for contributing! You should also consider submitting this patch to upstream wireguard-go! |
Contributor
Author
|
Hm true, I could look into it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Improve Windows data-plane performance by batching Wintun receives and RIO transmits.
The RIO path now reserves and submits an entire packet batch under one lock,
uses deferred sends followed by a single commit, and retains an immediate-send
fast path for single-packet traffic. The maximum Windows packet batch size is
increased from 16 to 32 based on throughput and latency testing.
Changes
RIO_MSG_DEFERand oneRIO_MSG_COMMIT_ONLYrequest.on latency-sensitive traffic.
Capacity is reserved before submitting deferred requests. This avoids waiting
for completions from requests that Windows has not yet committed.
Performance
Tests ran from a Windows 11 Pro system with an Intel i7-6700K to a Linux Nylon
endpoint over a gigabit Ethernet switch and a direct Nylon link.
A bounded A/B/A comparison of the final batch-size adjustment produced:
For the 64-byte workload, batch 32 delivered approximately 70% more traffic
than the mean of the controls, reduced loss by 23.9 percentage points, and used
approximately 27% less Nylon CPU time per delivered bit.
TCP and normal-packet UDP remained within the variability of the bracketing
controls. Batch sizes of 8 and 64 were also tested: 8 was slower, while 64
materially regressed normal-packet UDP throughput.
Latency
An A/B/A test using a temporary UDP echo endpoint found no measurable latency
regression from increasing the batch size:
The single-packet RIO fast path also preserved batching throughput while
removing the extra defer/commit operation from interactive traffic.
Profiling
A symbolized 20-second CPU profile during bounded 64-byte UDP traffic showed:
runtime.cgocall: 85.86% of sampled CPU time;RIOSendEx: approximately 40% of cumulative samples;This indicates that the remaining Windows cost is predominantly at the Windows
API boundary rather than in Nylon traffic control or encryption.
Validation
go test ./...suite passes.handling, failed-send rollback, and immediate/deferred send selection.