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]

Message-ID: <CA+h21ho+UqUBY-T+Q=zzboyG1WbGofJ4pboY4_e-fx+0cb5SAg@mail.gmail.com>
Date:   Sat, 23 Nov 2019 23:54:17 +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:47, Florian Fainelli <f.fainelli@...il.com> wrote:
> On 11/23/2019 1:29 PM, Vladimir Oltean wrote:
> > 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:

[snip]

> >>>> 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?
>
> I am afraid so, given that the NETDEV_CHANGEMTU even for which
> br_device_event() listens to and processes with br_mtu_auto_adjust()
> would lead to selecting the lowest MTU again. Unfortunately, I don't
> really see a way to solve that other than walk all ports (which could be
> any network device driver) and ask them if they support the new MTU of
> that other port, and if so, commit, else rollback. Do you see another way?
> --
> Florian

Something like that would be preferable. I think it would be
frustrating for the bridge to restore the old MTU right after you
change it. I have no idea how hard it would be to prevent the bridge
from doing this. I'll poke it with a stick and see what happens.

-Vladimir