Question: stmmac xmit: GSO vs TAPRIO max-sdu

["Russell King (Oracle)" <linux@armlinux.org.uk>]

Hi,

I've recently been looking at stmmac's descriptor code (and finding a
few bugs along the way...) I think I've found another bug.

stmmac implements various TC offloading, including some TAPRIO support.
This supports max_sdu, but it seems it is only implemented for the
non-GSO path:

        if (skb_is_gso(skb) &&
            skb_shinfo(skb)->gso_type & priv->gso_enabled_types)
                return stmmac_tso_xmit(skb, dev);

        if (priv->est && priv->est->enable &&
            priv->est->max_sdu[queue]) {
                sdu_len = skb->len;
                /* Add VLAN tag length if VLAN tag insertion offload is requeste+d */
                if (priv->dma_cap.vlins && skb_vlan_tag_present(skb))
                        sdu_len += VLAN_HLEN;
                if (sdu_len > priv->est->max_sdu[queue]) {
                        priv->xstats.max_sdu_txq_drop[queue]++;
                        goto max_sdu_err;
                }
        }

stmmac_tso_xmit() doesn't do any max_sdu checks. Is this correct, or
should the order of the above two if() statements be reversed so the
max_sdu check is also done for TSO?

(The TSO check in the above code will look different form what's
currently in net-next, as I already have a large pile of cleanups in
this area. However, it is functionally identical.)

Another question arises: gso_enabled_types is modified in
stmmac_set_features(). Is it possible that there are GSO packets
in the higher level networking queues while the netdev features are
changed, which could result in GSO packets being passed into the
netdev after e.g. GSO has been disabled, or are we guaranteed that
after .ndo_set_features() has been called, we won't be passed any
GSO packets?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!