Hi Alexis,
On Thu, Aug 10, 2023 at 11:36:50AM +0200, alexis.lothore@xxxxxxxxxxx wrote:
> + if (flags.mask & BR_FLOOD) {
> + val = flags.val & BR_FLOOD ? BIT(port) : 0;
> + a5psw_reg_rmw(a5psw, A5PSW_UCAST_DEF_MASK, BIT(port), val);
> + }
> +
> + if (flags.mask & BR_MCAST_FLOOD) {
> + val = flags.val & BR_MCAST_FLOOD ? BIT(port) : 0;
> + a5psw_reg_rmw(a5psw, A5PSW_MCAST_DEF_MASK, BIT(port), val);
> + }
> +
> + if (flags.mask & BR_BCAST_FLOOD) {
> + val = flags.val & BR_BCAST_FLOOD ? BIT(port) : 0;
> + a5psw_reg_rmw(a5psw, A5PSW_BCAST_DEF_MASK, BIT(port), val);
> + }
These 3 port masks will only do what you expect while the bridge has
vlan_filtering=0, correct? When vlan_filtering=1, packets classified to
a VLAN which don't hit any FDB entry will be always flooded to all ports
in that VLAN, correct?
Maybe you could restrict transitions to flooding disabled on ports with
vlan_filtering 1, and restrict transitions to vlan_filtering 1 on ports
with flooding disabled. Or at least add some comments about the
limitations. I wouldn't want subtle incompatibilities between the
hardware design and Linux' expectations to go under the radar like this.
