Re: [PATCH net-next 00/10] DSA unicast filtering

[Florian Fainelli <f.fainelli@gmail.com>]

Hi Vladimir,

On 3/2/2022 11:14 AM, Vladimir Oltean wrote:
> 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.

Thanks a lot for submitting this, really happy to see a solution being 
brought upstream. I will be reviewing this in more details later on, but 
from where I left a few years ago, the two challenges that I had are 
outlined below, and I believe we have not quite addressed them yet:

- for switches that implement global VLAN filtering, upper VLAN 
interfaces on top of standalone ports would require programming FDB and 
MDB entries with the appropriate VLAN ID, however there is no such 
tracking today AFAICT, so we are not yet solving those use cases yet, right?

- what if the switch does not support FDB/MDB isolation, what would be 
our options here? As you might remember from a few months ago, the 
Broadcom roboswitch do not have any isolation, but what they can do is 
internally tag Ethernet frames with two VLAN tags, an that may be used 
as a form of isolation

> 
> Vladimir Oltean (10):
>    net: dsa: remove workarounds for changing master promisc/allmulti only
>      while up
>    net: dsa: rename the host FDB and MDB methods to contain the "bridge"
>      namespace
>    net: dsa: install secondary unicast and multicast addresses as host
>      FDB/MDB
>    net: dsa: install the primary unicast MAC address as standalone port
>      host FDB
>    net: dsa: manage flooding on the CPU ports
>    net: dsa: felix: migrate host FDB and MDB entries when changing tag
>      proto
>    net: dsa: felix: migrate flood settings from NPI to tag_8021q CPU port
>    net: dsa: felix: start off with flooding disabled on the CPU port
>    net: dsa: felix: stop clearing CPU flooding in felix_setup_tag_8021q
>    net: mscc: ocelot: accept configuring bridge port flags on the NPI
>      port
> 
>   drivers/net/dsa/ocelot/felix.c     | 241 ++++++++++++++++++++------
>   drivers/net/ethernet/mscc/ocelot.c |   3 +
>   include/net/dsa.h                  |   7 +
>   net/dsa/dsa.c                      |  40 +++++
>   net/dsa/dsa_priv.h                 |  53 +++++-
>   net/dsa/port.c                     | 160 +++++++++++++-----
>   net/dsa/slave.c                    | 261 +++++++++++++++++++++++------
>   7 files changed, 609 insertions(+), 156 deletions(-)
> 

-- 
Florian