[PATCH net-next 2/2] net: stmmac: simplify GSO/TSO test in stmmac_xmit()
Russell King (Oracle)
linux at armlinux.org.uk
Sat Mar 28 01:24:37 PDT 2026
On Fri, Mar 27, 2026 at 09:40:09AM +0000, Russell King (Oracle) wrote:
> The test in stmmac_xmit() to see whether we should pass the skbuff to
> stmmac_tso_xmit() is more complex than it needs to be. This test can
> be simplified by storing the mask of GSO types that we will pass, and
> setting it according to the enabled features.
>
> Note that "tso" is a mis-nomer since commit b776620651a1 ("net:
> stmmac: Implement UDP Segmentation Offload"). Also note that this
> commit controls both via the TSO feature. We preserve this behaviour
> in this commit.
>
> Also, this commit unconditionally accessed skb_shinfo(skb)->gso_type
> for all frames, even when skb_is_gso() was false. This access is
> eliminated.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
AI review of this patch regurgitates Jakub's point that was discussed.
> @@ -3700,7 +3700,7 @@ static int stmmac_hw_setup(struct net_device *dev)
> stmmac_set_rings_length(priv);
>
> /* Enable TSO */
> - if (priv->tso) {
> + if (priv->gso_enabled_types) {
> for (chan = 0; chan < tx_cnt; chan++) {
> struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[chan];
>
...
> @@ -7828,7 +7834,7 @@ static int __stmmac_dvr_probe(struct device *device,
> ndev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
> if (priv->plat->core_type == DWMAC_CORE_GMAC4)
> ndev->hw_features |= NETIF_F_GSO_UDP_L4;
> - priv->tso = true;
> + stmmac_set_gso_types(priv, true);
Clearly, the issue it is regurgitating has been there for a long time
and isn't a new issue introduced by this patch.
AI needs to stop doing this, because it is encouraging multiple changes
in a single patch, which is against the normal kernel process.
As already pointed out, there are multiple issues with stmmac TSO
support, particularly with glue drivers that enable TSO on some
queues/channels and not others, since netdev core TSO support is
global across all channels.
So, won't the AI response in this patch - it's just another pre-
existing issue that needs fixing in a separate patch.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
More information about the linux-arm-kernel
mailing list