fix(connlib): correctly compute the GSO batch size#8754
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
0b96cd7 to
fa73c6d
Compare
Member
Author
2f4e0ba to
e2f4745
Compare
jamilbk
reviewed
Apr 11, 2025
Member
Author
|
All good, this is ready to merge. The problems I was facing locally ended up being something else. |
2159add to
6fd2a82
Compare
6fd2a82 to
1fd1784
Compare
jamilbk
approved these changes
Apr 12, 2025
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.

We are currently naively chunking our buffer into
segment_size * max_gso_segments().max_gso_segmentsis by default 64. Assuming we processed several IP packets, this would quickly balloon to a size that the kernel cannot handle. For example, during aniperf3run, we receive a lot of packets at maximum MTU size (1280). With the overhead that we are adding to the packet, this results in a UDP payload size of 1320.That is way too large for the kernel to handle and it will fail the
sendmsgcall withEMSGSIZE. Unfortunately, this error wasn't surfaced becausequinn_udphandles it internally because it can also happen as a result of MTU probes.We've already patched
quinn_udpin the past to move the handling of more quinn-specific errors to the infalliblesendfunction. The same is being done for this error in quinn-rs/quinn#2199.Resolves: #8699