Re: warnings from MTU setting on switch ports

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Mon, Nov 30, 2020 at 11:13:39PM +0100, Rasmus Villemoes wrote:
> On 30/11/2020 17.04, Vladimir Oltean wrote:
> > Hi Rasmus,
> >
> > On Mon, Nov 30, 2020 at 03:30:50PM +0100, Rasmus Villemoes wrote:
> >> Hi,
> >>
> >> Updating our mpc8309 board to 5.9, we're starting to get
> >>
> >> [    0.709832] mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU on port 0
> >> [    0.720721] mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU on port 1
> >> [    0.731002] mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU on port 2
> >> [    0.741333] mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU on port 3
> >> [    0.752220] mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU on port 4
> >> [    0.764231] eth1: mtu greater than device maximum
> >> [    0.769022] ucc_geth e0102000.ethernet eth1: error -22 setting MTU to include DSA overhead
> >>
> >> So it does say "nonfatal", but do we have to live with those warnings on
> >> every boot going forward, or is there something that we could do to
> >> silence it?
> >>
> >> It's a mv88e6250 switch with cpu port connected to a ucc_geth interface;
> >> the ucc_geth driver indeed does not implement ndo_change_mtu and has
> >> ->max_mtu set to the default of 1500.
> >
> > To suppress the warning:
> >
> > commit 4349abdb409b04a5ed4ca4d2c1df7ef0cc16f6bd
> > Author: Vladimir Oltean <olteanv@gmail.com>
> > Date:   Tue Sep 8 02:25:56 2020 +0300
> >
> >     net: dsa: don't print non-fatal MTU error if not supported
> >
>
> Thanks, but I don't think that will change anything. -34 is -ERANGE.

Yup, I thought of that after responding.

> > But you might also want to look into adding .ndo_change_mtu for
> > ucc_geth.
>
> Well, that was what I first did, but I'm incapable of making sense of
> the QE reference manual. Perhaps, given the domain of your email
> address, you could poke someone that might know what would need to be done?

Well, you could poke Leo Li, the QUICC engine maintainer, yourself too.
What exactly from the QEIWRM.pdf are you incapable of making sense of?

The MFLR register appears to be at offset 0x4c within the Rx Global
Parameter RAM.

> > If you are able to pass MTU-sized traffic through your
> > mv88e6085, then it is probably the case that the mpc8309 already
> > supports larger packets than 1500 bytes, and it is simply a matter of
> > letting the stack know about that.
>
> Perhaps, but I don't know how I should test that given that 1500
> give-or-take is hardcoded.

Very simply, you could run iperf3 or any other TCP stream (ssh,
whatever). That will eventually increase the TCP segment size to the
MTU. If the TCP stream doesn't hang, then the QUICC engine can receive
packets over the MTU.

> FWIW, on a 4.19 kernel, I can do 'ping -s X -M do' for X up to 1472
> for IPv4 and 1452 for IPv6, but I don't think that tells me much about
> what the hardware could do.

IP will get fragmented by the stack to the interface's MTU.

> A thought: Shouldn't the initialization of slave_dev->max_mtu in
> dsa_slave_create() be capped by master->max_mtu minus tag overhead?

Talk to Andrew:
https://www.spinics.net/lists/netdev/msg645810.html