netdev - Re: [PATCH net-next 1/3] net: dsa: Configure the MTU for switch ports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 23 Nov 2019 23:29:16 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: dsa: Configure the MTU for switch ports

On Sat, 23 Nov 2019 at 23:14, Florian Fainelli <f.fainelli@...il.com> wrote:
>
>
>
> On 11/23/2019 12:46 PM, Vladimir Oltean wrote:
> >
> > Correct. I was actually held back a bit while looking at Andrew's
> > patch dc0fe7d47f9f ("net: dsa: Set the master device's MTU to account
> > for DSA overheads") where he basically discarded errors, so that's the
> > approach I took too (thinking that some DSA masters would not have ops
> > for changing or reporting the MTU).
> >
> >> I had prepared a patch series with Murali doing nearly the same thing
> >> and targeting Broadcom switches nearly a year ago but since I never got
> >> feedback whether this worked properly for the use case he was after, I
> >> did not submit it since I did not need it personally and found it to be
> >> a nice can of worms.
> >>
> >
> > Nice, do you mind if I take your series instead then?
>
> Not at all, if it works, please go ahead, not sure how hard it is going
> to be to rebase.
>
> >
> >> Another thing that I had not gotten around testing was making sure that
> >> when a slave_dev gets enslaved as a bridge port member, that bridge MTU
> >> normalization would kick in and make sure that if you have say: port 0
> >> configured with MTU 1500 and port 1 configured with MTU 9000, the bridge
> >> would normalize to MTU 1500 as you would expect.
> >>
> >
> > Nope, that doesn't happen by default, at least in my implementation.
> > Is there code in the bridge core for it?
>
> net/bridge/br_if.c::br_mtu_auto_adjust() takes care of adjusting the
> bridge master device's MTU based on the minimum MTU of all ports within
> the bridge, but what it seems to be missing is ensuring that if bridge
> ports are enslaved, and those bridge ports happen to be part of the same
> switch id (similar decision path to setting skb->fwd_offload_mark), then
> the bridge port's MTU should also be auto adjusted. mlxsw also supports
> changing the MTU, so I am surprised this is not something they fixed
> already.
>

But then how would you even change a bridged interface's MTU? Delete
bridge, change MTU of all ports to same value, create bridge again?

> >
> >> https://github.com/ffainelli/linux/commits/dsa-mtu
> >>
> >> This should be a DSA switch fabric notifier IMHO because changing the
> >> MTU on an user port implies changing the MTU on every DSA port in
> >> between plus the CPU port. Your approach here works for the first
> >> upstream port, but not for the ones in between, and there can be more,
> >> as is common with the ZII devel Rev. B and C boards.
> >
> > Yes, correct. Your patch implements notifiers which is definitely
> > good. I don't have a cascaded setup to test yet (my Turris Mox was
> > supposed to arrive but for some reason it was returned to the seller
> > by the shipping company...).
>
> Andrew and Vivien may know whether it is possible to get you a ZII Devel
> rev. B or C since those have 3 switches in the fabric and have
> constituted nice test platforms. Not sure if there is a version with a
> CPU port that is Gigabit capable though.

Well, I've already ordered it again, this time with more expensive
shipping... Hopefully I got their hint right.

> --
> Florian