On Mon, Nov 09, 2020 at 02:30, Vladimir Oltean <olte...@gmail.com> wrote:
> On Mon, Nov 09, 2020 at 12:59:39AM +0100, Andrew Lunn wrote:
>> 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. Should we add more arguments to
> the API?
I don't think that would help. You would essentially be trading one
situation where station moves causes loss of traffic for another
one. But now you have also increased the background load of an already
choked resource, the MDIO bus.
At least on mv88e6xxx, your only option to allow the hardware to move
the station to another port autonomously is to add the entry as a
dynamically learnt one. However, since the switch does not perform any
SA learning on the CPU port in this world, the entry would have to be
refreshed by software, otherwise it would just age out.
Then you run in to this situation:
A and B are communicating.
br0
.----'|'----.
| | |
swp0 swp1 wlan0
| |
A B
The switch's FDB:
A: swp0
B: cpu0 (due to this patchset)
Now B roams to an AP somewhere behind swp1 and continues to communicate
with A.
br0
.----'|'----.
| | |
swp0 swp1 wlan0
| |
A B
The switch's FDB:
A: swp0
B: swp1
But br0 sees none of this, so at whatever interval we choose we will
refresh the FDB, moving the station back to the cpu:
A: swp0
B: cpu0
So now you have traded the issue of having to wait for the hardware to
age out its entry, to the issue of having to wait for br0 to age out its
entry. Right?
