All the buffers and registers are already set up appropriately for an
MTU slightly above 1500, so we just need to expose this to the
networking stack. AFAICT, there's no need to implement .ndo_change_mtu
when the receive buffers are always set up to support the max_mtu.
This fixes several warnings during boot on our mpc8309-board with an
embedded mv88e6250 switch:
mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
...
mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
The last line explains what the DSA stack tries to do: achieving an MTU
of 1500 on-the-wire requires that the master netdevice connected to
the CPU port supports an MTU of 1500+the tagging overhead.
Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Cc: Vladimir Oltean <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
---
drivers/net/ethernet/freescale/ucc_geth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index 714b501be7d0..380c1f09adaf 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3889,6 +3889,7 @@ static int ucc_geth_probe(struct platform_device* ofdev)
INIT_WORK(&ugeth->timeout_work, ucc_geth_timeout_work);
netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, 64);
dev->mtu = 1500;
+ dev->max_mtu = 1518;
ugeth->msg_enable = netif_msg_init(debug.msg_enable, UGETH_MSG_DEFAULT);
ugeth->phy_interface = phy_interface;
--
2.23.0
On Sat, Dec 05, 2020 at 08:17:24PM +0100, Rasmus Villemoes wrote:
> All the buffers and registers are already set up appropriately for an
> MTU slightly above 1500, so we just need to expose this to the
> networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> when the receive buffers are always set up to support the max_mtu.
>
> This fixes several warnings during boot on our mpc8309-board with an
> embedded mv88e6250 switch:
>
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> ...
> mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
>
> The last line explains what the DSA stack tries to do: achieving an MTU
> of 1500 on-the-wire requires that the master netdevice connected to
> the CPU port supports an MTU of 1500+the tagging overhead.
>
> Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> Cc: Vladimir Oltean <[email protected]>
> Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
On Thu, 2020-12-10 at 02:25 +0100, Andrew Lunn wrote:
> On Sat, Dec 05, 2020 at 08:17:24PM +0100, Rasmus Villemoes wrote:
> > All the buffers and registers are already set up appropriately for an
> > MTU slightly above 1500, so we just need to expose this to the
> > networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> > when the receive buffers are always set up to support the max_mtu.
> >
> > This fixes several warnings during boot on our mpc8309-board with an
> > embedded mv88e6250 switch:
> >
> > mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> > ...
> > mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> > ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
> >
> > The last line explains what the DSA stack tries to do: achieving an MTU
> > of 1500 on-the-wire requires that the master netdevice connected to
> > the CPU port supports an MTU of 1500+the tagging overhead.
> >
> > Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> > Cc: Vladimir Oltean <[email protected]>
> > Signed-off-by: Rasmus Villemoes <[email protected]>
>
> Reviewed-by: Andrew Lunn <[email protected]>
>
> Andrew
I don't see this in any kernel, seems stuck? Maybe because the series as a whole is not approved?
Jocke
On Tue, Jan 05, 2021 at 02:17:42PM +0000, Joakim Tjernlund wrote:
> On Thu, 2020-12-10 at 02:25 +0100, Andrew Lunn wrote:
> > On Sat, Dec 05, 2020 at 08:17:24PM +0100, Rasmus Villemoes wrote:
> > > All the buffers and registers are already set up appropriately for an
> > > MTU slightly above 1500, so we just need to expose this to the
> > > networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> > > when the receive buffers are always set up to support the max_mtu.
> > >
> > > This fixes several warnings during boot on our mpc8309-board with an
> > > embedded mv88e6250 switch:
> > >
> > > mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> > > ...
> > > mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> > > ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
> > >
> > > The last line explains what the DSA stack tries to do: achieving an MTU
> > > of 1500 on-the-wire requires that the master netdevice connected to
> > > the CPU port supports an MTU of 1500+the tagging overhead.
> > >
> > > Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> > > Cc: Vladimir Oltean <[email protected]>
> > > Signed-off-by: Rasmus Villemoes <[email protected]>
> >
> > Reviewed-by: Andrew Lunn <[email protected]>
> >
> > ????Andrew
>
> I don't see this in any kernel, seems stuck? Maybe because the series as a whole is not approved?
Hi Joakim
When was it posted? If it was while netdev was closed during the merge
window, you need to repost.
You should be able to see the status in the netdev patchwork instance
https://patchwork.kernel.org/project/netdevbpf/list/
Andrew
On Tue, 2021-01-05 at 15:33 +0100, Andrew Lunn wrote:
> On Tue, Jan 05, 2021 at 02:17:42PM +0000, Joakim Tjernlund wrote:
> > On Thu, 2020-12-10 at 02:25 +0100, Andrew Lunn wrote:
> > > On Sat, Dec 05, 2020 at 08:17:24PM +0100, Rasmus Villemoes wrote:
> > > > All the buffers and registers are already set up appropriately for an
> > > > MTU slightly above 1500, so we just need to expose this to the
> > > > networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> > > > when the receive buffers are always set up to support the max_mtu.
> > > >
> > > > This fixes several warnings during boot on our mpc8309-board with an
> > > > embedded mv88e6250 switch:
> > > >
> > > > mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 0
> > > > ...
> > > > mv88e6085 mdio@e0102120:10: nonfatal error -34 setting MTU 1500 on port 4
> > > > ucc_geth e0102000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead
> > > >
> > > > The last line explains what the DSA stack tries to do: achieving an MTU
> > > > of 1500 on-the-wire requires that the master netdevice connected to
> > > > the CPU port supports an MTU of 1500+the tagging overhead.
> > > >
> > > > Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
> > > > Cc: Vladimir Oltean <[email protected]>
> > > > Signed-off-by: Rasmus Villemoes <[email protected]>
> > >
> > > Reviewed-by: Andrew Lunn <[email protected]>
> > >
> > > Andrew
> >
> > I don't see this in any kernel, seems stuck? Maybe because the series as a whole is not approved?
>
> Hi Joakim
>
> When was it posted? If it was while netdev was closed during the merge
> window, you need to repost.
>
> You should be able to see the status in the netdev patchwork instance
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fnetdevbpf%2Flist%2F&data=04%7C01%7CJoakim.Tjernlund%40infinera.com%7C25615f4c00a44959810208d8b186e496%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637454540217112252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=00l%2FBYyxnAoshH1aZMwEznVFQZXwaYGe3pTo6R3RG3Q%3D&reserved=0
>
> Andrew
Hi Andrew
I found here:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
Seem to be underway but stable isn't included, I think it should be.
Jocke
> Hi Andrew
>
> I found here:
> https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
>
> Seem to be underway but stable isn't included, I think it should be.
Stable should happen, since this was posted with [net,v2,3/3]. David
or Jakub handles stable for netdev. Give it a few more days. If not,
ask Jakub what is happening.
Andrew