On 6/9/26 4:53 AM, Jakub Kicinski wrote: > On Sat, 6 Jun 2026 17:24:01 -0700 Jakub Kicinski wrote: >> + /* Signal over-coalescing explicitly, it's a hard failure, unlike >> + * under-coalescing which could be timing- or loss-related. >> + */ >> + if (num_pkt < correct_num_pkts && bytes_received == bytes_expected) >> + error(EXIT_OVER_COALESCE, 0, >> + "over-coalesced: got %d pkts vs expected %d (%d B)", >> + num_pkt, correct_num_pkts, bytes_received); > > Sashiko complains that this condition may mis-fire if we lose a zero-len > RST or ACK. This is true, tho, if the device drops pure acks ignoring > failures where ack disappeared puts us back at risk of false negatives. > Happy to respin but feels like we only have bad choices here..
My personal take here is that packet loss at (very) low rate in a controlled environment should be threaded as fatal: I think the patch in the current form is the better option. /P
