Derive the GSO segment size from the batch - #200
Open
benoitc wants to merge 1 commit into
Open
Conversation
The uniformity check compared every packet against a configured gso_size that nothing sets, so it stayed at 1200 while 1-RTT packets follow the max datagram size and the GSO path never ran. - derive the segment size from the batch and pass it to the cmsg, so the kernel segments on the boundaries the packets actually have - require the last packet to be no larger than the segment size - split writes over 64 segments or 64 KB across several sendmsg calls - send the chunks a partial write never reached instead of losing them - request GSO per message only; a socket-level UDP_SEGMENT on the listener path segmented every datagram, handshake packets included - count segmented batches separately in gso_flushes: batch_flushes and packets_coalesced advance on both flush paths, so the download test's ratio over them stayed green while the GSO path was dead
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
1 participant
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.
Fixes #196.
The GSO path never ran: the uniformity check compared every packet against a
gso_sizethat no caller sets, so it stayed at the 1200 default while 1-RTT packets follow the current max datagram size. Deriving the size from the batch is the only value that can be right.That alone is not enough to turn it on.
flush_gso/1also read the segment size from the record rather than from the batch, so making the check pass still told the kernel to cut at 1200 in the middle of 1398-byte packets, which is theidle_timeoutreported in the issue. The listener path also set a socket-levelUDP_SEGMENT, which segments every datagram including handshake packets; GSO is now requested per message only, asbuild_socket_statealready documented.CI could not catch any of this because
batch_flushesandpackets_coalescedadvance on the individual path too, so the download test's ratio measured batching rather than offload.gso_flushescounts only the batches the kernel segmented, and the Linux job now asserts it advanced.@jbevemyr this is your report; if you can retest on your setup that would be welcome, since the maintainer's machine cannot exercise the path.