On Thu, Oct 29, 2020 at 11:32:36AM +0800, DENG Qingfang wrote:
> On Thu, Oct 29, 2020 at 2:31 AM Vladimir Oltean <olte...@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
