[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260211090013.12991cd0@kernel.org>
Date: Wed, 11 Feb 2026 09:00:13 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
shuah@...nel.org, willemb@...gle.com, petrm@...dia.com,
donald.hunter@...il.com, michael.chan@...adcom.com,
pavan.chebbi@...adcom.com, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v2 6/9] selftests: drv-net: gro: use SO_TXTIME
to schedule packets together
On Tue, 10 Feb 2026 23:21:07 -0500 Willem de Bruijn wrote:
> > > 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.
> >
> > It works but requires that we either modify the qdisc config to set
> > a orphan_mask of 1, or somehow set the skb->hash on the AF_PACKET skbs.
>
> Oh right, fq_classify does not use skb->sk for packet sockets because
> they are in default sk_state TCP_CLOSE.
>
> And this is by design, as clearly documented, as packet sockets should
> not be assumed to be a single flow:
>
> } else if (sk->sk_state == TCP_CLOSE) {
> unsigned long hash = skb_get_hash(skb) & q->orphan_mask;
> /*
> * Sockets in TCP_CLOSE are non connected.
> * Typical use case is UDP sockets, they can send packets
> * with sendto() to many different destinations.
> * We probably could use a generic bit advertising
> * non connected sockets, instead of sk_state == TCP_CLOSE,
> * if we care enough.
> */
> sk = (struct sock *)((hash << 1) | 1UL);
> }
>
> An orphan_mask of 1 sounds like an effective workaround.
>
> I don't see a way to force a specific skb_get_hash result across
> flows, given hashrnd.
So WDYT about the patch? I don't wanna tweak qdiscs on real interfaces.
It's way to hard to undo. IMHO either we keep the patch as is with its
limited effect or just drop it.
Powered by blists - more mailing lists