Re: [PATCH] net: dsa: mt7530: support setting MTU

[Jonathan McDowell <noodles@earth.li>]

On Thu, Oct 29, 2020 at 11:32:36AM +0800, DENG Qingfang wrote:
> On Thu, Oct 29, 2020 at 2:31 AM Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Thu, Oct 29, 2020 at 02:12:21AM +0800, DENG Qingfang wrote:
...
> > > +static int
> > > +mt7530_port_change_mtu(struct dsa_switch *ds, int port, int new_mtu)
> > > +{
> > > +     struct mt7530_priv *priv = ds->priv;
> > > +     int length;
> > > +
> > > +     /* When a new MTU is set, DSA always set the CPU port's MTU to the largest MTU
> > > +      * of the slave ports. Because the switch only has a global RX length register,
> > > +      * only allowing CPU port here is enough.
> > > +      */
> >
> > Good point, please tell that to Linus (cc) - I'm talking about
> > e0b2e0d8e669 ("net: dsa: rtl8366rb: Roof MTU for switch"),
> 
> And 6ae5834b983a ("net: dsa: b53: add MTU configuration support"),
> 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU"),
> f58d2598cf70 ("net: dsa: qca8k: implement the port MTU callbacks")
> 
> CC'd them as well.

qca8k tracks and use the maximum provided mtu; perhaps that could be
optimised by only allow the CPU port to be set but it feels a bit more
future proof (e.g. if/when we support multiple CPU ports).

> Also, the commit e0b2e0d8e669 states that the new_mtu parameter is L2
> frame length instead of L2 payload. But according to my tests, it is
> L2 payload (i.e. the same as the MTU shown in `ip link` or `ifconfig`.
> Is that right?

Certainly that's what I saw; qca8k sets the MTU to the provided MTU +
ETH_HLEN + ETH_FCS_LEN.

J.

-- 
Pretty please, with sugar on top, clean the f**king car.
This .sig brought to you by the letter J and the number 13
Product of the Republic of HuggieTag