Re: [PATCH net-next v2 6/9] selftests: drv-net: gro: use SO_TXTIME to schedule packets together

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

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 <petrm@nvidia.com>
> > > Signed-off-by: Jakub Kicinski <kuba@kernel.org>  
> > 
> > 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.