[PATCH net-next v2] net: stmmac: improve TSO/GSO queue selection

[Jakub Kicinski]

On Thu, 13 Aug 2026 22:36:29 +0200 Lorenzo Bianconi wrote:
> On Aug 12, Jakub Kicinski wrote:
> > On Wed, 12 Aug 2026 18:11:31 +0200 Lorenzo Bianconi wrote:  
> > > please drop this version, I will post v3 to fix some pending issues.  
> > 
> > FTR Russell was trying to fix TSO in this driver too, before giving up
> > (on us?). The direction he was following of clearing the TSO caps in
> > ndo_features_check and letting the stack GSO instead of all the weird
> > hacks this driver has seemed much more sane. But maybe I'm missing
> > something TBS specific here   
> 
> thx for the pointers. I reviewed Russell's commits and I guess we have two
> options here:
> 
> - manages all the TSO/GSO checks in ndo_features_check() (stmmac_features_check())
>   and disable TSO/GSO if the selected queue does not support checksum offload
>   or it has TBS enabled. In this case I guess we can drop ndo_select_queue()
>   callback completely (it does not make sense to me to always use queue 0 for
>   TSO/GSO packets, e.g. it does not allow proper mqprio offload).
>   Please note this approach would introduce some performance regressions with
>   respect of the previous implementation.
> - implements TSO/GSO checks in ndo_select_queue() callback
>   (stmmac_select_queue()) in order to keep TSO/GSO enabled if the selected
>   queue supports it and at the same time do not always use queue 0 for TSO/GSO
>   packets (proper qdisc offload). Please note this is patch I am proposing.
> 
> What do you think?

I don't know this driver, or how it's used.

From the commit message it sounds like "if the packet wants TSO and 
the queue has a scheduler enabled - take the packet to another queue".
Presumably you know why the TBS is enabled and whether the packet
should or should not be going to that queue in the first place if
you're sending the patch? What is the use case?