Jakub Kicinski wrote: > On Sun, 08 Feb 2026 21:39:38 -0500 Willem de Bruijn wrote: > > Jakub Kicinski wrote: > > > Longer packet sequence tests are quite flaky when the test is run > > > over a real network. Try to avoid at least the jitter on the sender > > > side by scheduling all the packets to be sent at once using SO_TXTIME. > > > Use hardcoded tx time of 5msec in the future. In my test increasing > > > this time past 2msec makes no difference so 5msec is plenty of margin. > > > Since we now expect more output buffering make sure to raise SNDBUF. > > > > > > Experimenting with long sequences I see frequent failures when sending > > > 200 packets, only 50-100 packets get coalesced. With this change > > > up to 1000 packets get coalesced relatively reliably. > > > > > > Reviewed-by: Petr Machata <[email protected]> > > > Signed-off-by: Jakub Kicinski <[email protected]> > > > > Does this require having FQ installed? I don't see any qdisc config > > in the GRO test. > > It's a bit of an opportunistic optimization. > > I initially intended it for for the "long sequence of packets" > test. But I failed to get AF_PACKET+FQ to cooperate sufficiently > to queue all of the packets in the same bucket. Otherwise FQ "sorts" > the packets, and breaks what the test is trying to do :(
I wonder what's going wrong here. fq_classify should pick the queue based on skb->sk also for packet sockets. And flow_queue_add should add the packets to the tail of the linear list if the delivery time is identical to that of the tail. > Oh, and as mentioned in the commit msg - this improvement is intended > for HW-GRO, which may have very low timeouts. The test already > configures timeout for SW GRO to a very high value, so don't think > we would gain anything from setting up FQ on veth/netdevsim for the > SW test. > > So IDK what to do with this patch. Maybe I should just drop it? > It _seemed_ useful, but I don't have enough datapoints to do a real > comparison of how much it improves reliability. It seems useful indeed.
