linux-kernel - Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO

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: <20201109123111.ine2q244o5zyprvn@skbuf>
Date:   Mon, 9 Nov 2020 14:31:11 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     Andrew Lunn <andrew@...n.ch>, DENG Qingfang <dqfext@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
        Marek Behun <marek.behun@....cz>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: listen for
 SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

On Mon, Nov 09, 2020 at 12:05:19PM +0100, Tobias Waldekranz wrote:
> On Mon, Nov 09, 2020 at 12:03, Vladimir Oltean <olteanv@...il.com> wrote:
> > On Mon, Nov 09, 2020 at 09:09:37AM +0100, Tobias Waldekranz wrote:
> >> one. But now you have also increased the background load of an already
> >> choked resource, the MDIO bus.
> >
> > In practice, DSA switches are already very demanding of their management
> > interface throughput, for PTP and things like that. I do expect that if
> > you spent any significant amount of time with DSA, you already know the
> > ins and outs of your MDIO/SPI/I2C controller and it would already be
> > optimized for efficiency. But ok, we can add this to the list of cons.
>
> You are arguing for my position though, no? Yes it is demanding; that is
> why we must allocate it carefully.

Yes, if the change brings additional load to the MDIO/SPI/I2C link and
doesn't bring any benefit, then it makes sense to skip it.

> > So there you have it, it's not that bad. More work needs to be done, but
> > IMO it's still workable.
>
> If you bypass learning on all frames sent from the CPU (as today), yes I
> agree that you should be able to solve it with static entries. But I
> think that you will have lots of weird problems with initial packet loss
> as the FDB updates are not synchronous with the packet flow. I.e. the
> bridge will tell DSA to update the entry, but the update in HW will
> occur some time later when the workqueue actually performs the
> operation.

I don't know how bad this is in practice. It's surely better than
waiting 5 minutes though.

> > But now maybe it makes more sense to treat the switches that perform
> > hardware SA learning on the CPU port separately, after I've digested
> > this a bit.
>
> Yes, please. Because it will be impossible to add tx forward offloading
> otherwise.

Ok, so this change, when applied to mv88e6xxx, would preclude you from
using FORWARD frames for your other application of that feature, unless
you explicitly turn off SA learning for FORWARD frames coming the CPU
port, case in which you would still be ok.

I need to sit on this for a while. How many DSA drivers do we have that
don't do SA learning in hardware for CPU-injected packets? ocelot/felix
and mv88e6xxx? Who else? Because if there aren't that many (or any at
all except for these two), then I could try to spend some time and see
how Felix behaves when I send FORWARD frames to it. Then we could go on
full blast with the other alternative, to force-enable address learning
from the CPU port, and declare this one as too complicated and not worth
the effort.