Re: [RFC PATCH v2 net-next 05/17] net: bridge: implement unicast filtering for the bridge device

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, Feb 22, 2022 at 06:54:13PM +0200, Ido Schimmel wrote:
> On Tue, Feb 22, 2022 at 01:21:53PM +0200, Vladimir Oltean wrote:
> > Hi Ido,
> > 
> > On Mon, 1 Mar 2021 at 17:22, Ido Schimmel <idosch@idosch.org> wrote:
> > >
> > > On Wed, Feb 24, 2021 at 01:43:38PM +0200, Vladimir Oltean wrote:
> > > > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > >
> > > > The bridge device currently goes into promiscuous mode when it has an
> > > > upper with a different MAC address than itself. But it could do better:
> > > > it could sync the MAC addresses of its uppers to the software FDB, as
> > > > local entries pointing to the bridge itself. This is compatible with
> > > > switchdev, since drivers are now instructed to trap these MAC addresses
> > > > to the CPU.
> > > >
> > > > Note that the dev_uc_add API does not propagate VLAN ID, so this only
> > > > works for VLAN-unaware bridges.
> > >
> > > IOW, it breaks VLAN-aware bridges...
> > >
> > > I understand that you do not want to track bridge uppers, but once you
> > > look beyond L2 you will need to do it anyway.
> > >
> > > Currently, you only care about getting packets with specific DMACs to
> > > the CPU. With L3 offload you will need to send these packets to your
> > > router block instead and track other attributes of these uppers such as
> > > their MTU so that the hardware will know to generate MTU exceptions. In
> > > addition, the hardware needs to know the MAC addresses of these uppers
> > > so that it will rewrite the SMAC of forwarded packets.
> > 
> > Ok, let's say I want to track bridge uppers. How can I track the changes to
> > those interfaces' secondary addresses, in a way that keeps the association
> > with their VLAN ID, if those uppers are VLAN interfaces?
> 
> Hi,
> 
> I'm not sure what you mean by "secondary addresses", but the canonical
> way that I'm familiar with of adding MAC addresses to a netdev is to use
> macvlan uppers. For example:
> 
> # ip link add name br0 up type bridge vlan_filtering 1
> # ip link add link br0 name br0.10 type vlan id 10
> # ip link add link br0.10 name br0.10-v address 00:11:22:33:44:55 type macvlan mode private
> 
> keepalived uses it in VRRP virtual MAC mode (for example):
> https://github.com/acassen/keepalived/blob/master/doc/NOTE_vrrp_vmac.txt
> 
> In the software data path, this will result in br0 transitioning to
> promisc mode and passing all the packets to upper devices that will
> filter them.
> 
> In the hardware data path, you can apply promisc mode by flooding to
> your CPU port (I believe this is what you are trying to avoid) or
> install an FDB entry <00:11:22:33:44:55,10> that points to your CPU
> port.

Maybe the terminology is not the best, but by secondary addresses I mean
struct net_device :: uc and mc. To my knowledge, the MAC address of
vlan/macvlan uppers is not the only way in which these lists can be
populated. There is also AF_PACKET UAPI for PACKET_MR_MULTICAST and
PACKET_MR_UNICAST, and this ends up calling dev_mc_add() and
dev_uc_add(). User space may use this API to add a secondary address to
a VLAN upper interface of a bridge.

The question was how can the bridge get notified of changes to those 2
lists of its upper interfaces?

If it monitors NETDEV_CHANGEUPPER it has access to those lists only when
an upper joins or leaves.
If it monitors NETDEV_CHANGEADDR, it gets notified only to changes on
the primary addresses of the uppers (dev_addr and dev_addrs).
If it implements ndo_set_rx_mode (this patch), it has all the addresses
synced to it, but they lack a VLAN ID, because every address lacks
further information about which device added it.

If there's logic in the mlxsw driver that does this, unfortunately I
haven't found it.