[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201109010621.GE1417181@lunn.ch>
Date: Mon, 9 Nov 2020 02:06:21 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: 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,
Tobias Waldekranz <tobias@...dekranz.com>,
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
> > We also need to make sure the static entries get removed correctly
> > when a host moves. The mv88e6xxx will not replace a static entry with
> > a dynamically learned one. It will probably rise an ATU violation
> > interrupt that frames have come in the wrong port.
>
> This is a good one. Currently every implementer of .port_fdb_add assumes
> a static entry is what we want, but that is not the case here. We want
> an entry that can expire or the switch can move it to a different port
> when there is evidence that it's wrong.
I doubt you will find any hardware that actually does this. I expect
there are static entries, and dynamic entries, and nothing
hybrid. After a move, we need to rely on a broadcast packet making its
way to the software bridge, which causes it to learn about the move,
and delete the static CPU entry from the hardware.
We can probably test this with having our wireless device move back
and forth a few times, so we can see the full cycle a few
times. Unfortunately, i don't have two boards with both a switch and
WiFi.
Andrew
Powered by blists - more mailing lists