Merge branch 'dsa-unicast-filtering'
authorDavid S. Miller <davem@davemloft.net>
Thu, 3 Mar 2022 14:15:31 +0000 (14:15 +0000)
committerDavid S. Miller <davem@davemloft.net>
Thu, 3 Mar 2022 14:15:31 +0000 (14:15 +0000)
commit6fb8661c8f97bb062d2ecc7a57591d38e6c4f8c8
tree30247092495e3758a688f96dc30c4bf53eeaa0d0
parent43113ff73453c231af2c8e700cb4ff8bca97cff6
parentac45520960234cfa4be89b5aa072ac0fc7e57c07
Merge branch 'dsa-unicast-filtering'

Vladimir Oltean says:

====================
DSA unicast filtering

This series doesn't attempt anything extremely brave, it just changes
the way in which standalone ports which support FDB isolation work.

Up until now, DSA has recommended that switch drivers configure
standalone ports in a separate VID/FID with learning disabled, and with
the CPU port as the only destination, reached trivially via flooding.
That works, except that standalone ports will deliver all packets to the
CPU. We can leverage the hardware FDB as a MAC DA filter, and disable
flooding towards the CPU port, to force the dropping of packets with
unknown MAC DA.

We handle port promiscuity by re-enabling flooding towards the CPU port.
This is relevant because the bridge puts its automatic (learning +
flooding) ports in promiscuous mode, and this makes some things work
automagically, like for example bridging with a foreign interface.
We don't delve yet into the territory of managing CPU flooding more
aggressively while under a bridge.

The only switch driver that benefits from this work right now is the
NXP LS1028A switch (felix). The others need to implement FDB isolation
first, before DSA is going to install entries to the port's standalone
database. Otherwise, these entries might collide with bridge FDB/MDB
entries.

This work was done mainly to have all the required features in place
before somebody starts seriously architecting DSA support for multiple
CPU ports. Otherwise it is much more difficult to bolt these features on
top of multiple CPU ports.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>