On Mon, Nov 30, 2020 at 11:13:39PM +0100, Rasmus Villemoes wrote:

On 30/11/2020 17.04, Vladimir Oltean wrote:

quoted

Hi Rasmus,

On Mon, Nov 30, 2020 at 03:30:50PM +0100, Rasmus Villemoes wrote:

quoted

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 [off-list ref]
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.

quoted

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.

quoted

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