Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags

[Vivien Didelot <vivien.didelot@gmail.com>]

Hi Russell,

On Tue, 19 Feb 2019 17:14:14 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> > > > > +static unsigned long mv88e6xxx_bridge_flags_support(struct dsa_switch *ds)
> > > > > +{
> > > > > +	struct mv88e6xxx_chip *chip = ds->priv;
> > > > > +	unsigned long support = 0;
> > > > > +
> > > > > +	if (chip->info->ops->port_set_egress_floods)
> > > > > +		support |= BR_FLOOD | BR_MCAST_FLOOD;
> > > > > +
> > > > > +	return support;
> > > > > +}
> > > > 
> > > > I think that it isn't necessary to propagate the notion of bridge flags down
> > > > to the DSA drivers. It might be just enough to add:
> > > > 
> > > >     port_egress_flood(dsa_switch *ds, int port, bool uc, bool mc)
> > > > 
> > > > to dsa_switch_ops and set BR_FLOOD | BR_MCAST_FLOOD from the DSA core,
> > > > if the targeted driver has ds->ops->port_set_egress_flood. What do you think?
> > > 
> > > There are two other flags that I haven't covered which the bridge code
> > > expects to be offloaded, and those are the broadcast flood flag and
> > > the learning flag.
> > 
> > I see. What does the bridge code do if these flags are set? Does it expect
> > the underlying devices to handle ff:ff:ff:ff:ff:ff magically or does it
> > program this entry into the bridged ports?
> 
> The bridge code defaults to all four flags set.  See new_nbp() in
> net/bridge/br_if.c:
> 
> 	p->flags = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
> 
> bridge(8) doesn't touch BR_BCAST_FLOOD, but it is made available to
> userspace via netlink and IFLA_BRPORT_BCAST_FLOOD.  Hence, there's
> no man page documentation for that flag.
> 
> According to br_flood() in net/bridge/br_forward.c, it controls
> whether broadcast frames are flooded to all ports or not.  Changing
> this flag is merely handled just like the multicast/unicast flooding
> flags - a call is made to set the offloaded flags, and if it isn't
> returned as being supported, a warning is printed.  No attempt is
> made to create or change a forwarding entry for the broadcast MAC
> address.

OK, thanks for the details. The programming of the broadcast MAC address
must be handled in the core then, I will move this from mv88e6xxx up to the
DSA layer later, but that's totally orthogonal here.

> 
> bridge(8) does document BR_LEARNING via IFLA_BRPORT_LEARNING:
> 
>        learning on or learning off
>               Controls whether a given port will learn MAC addresses from
>               received traffic or not. If learning if off, the bridge will end
>               up flooding any traffic for which it has no FDB entry. By
>               default this flag is on.
> 
> > In the latter case we have almost nothing to do. In the former case, we can
> > make the core call dsa_port_mdb_add on setup and when a VLAN is added.
> > 
> > mv88e6xxx tries to be smart and is already doing that and I'm really not a fan.
> > 
> > If tomorrow there's a switch capable of simply toggling a bit to do that,
> > we can add a new ops and skip the port_mdb_add call in the core.
> > 
> > > I know that the Marvell switches don't have a bit to control the
> > > broadcast flooding, that appears to be controlled via a static entry
> > > in the ATU which would have to be modified as the broadcast flood flag
> > > is manipulated.  I don't know how that is handled in other bridges.
> > > 
> > > Do we want to include the broadcast flood in the above prototype?
> > > If we go for this, how do we detect which options a switch supports?
> > 
> > If the necessary dsa_switch_ops routine is correctly prototyped, having it
> > implemented by a driver or not should be enough to inform the core that the
> > related feature(s) is/are supported by the switch.
> > 
> > I'll try to give a bit more context on why I'd prefer this approach, hoping
> > it makes sense: a switch driver does not need to understand bridge flags
> > per-se, the core should give enough abstraction to this layer (and any other
> > net-specifics). The core just needs to know if a driver can program this or
> > that. More importantly, it can easily become messy to maintain switch-cases
> > of arbitrary flags in all drivers and the core.
> 
> So, should we go the other way and have:
> 
> 	int (*port_learning)(struct dsa_switch *ds, int port, bool enable);
> 	int (*port_egress_flood_uc)(struct dsa_switch *ds, int port, bool enable);
> 	int (*port_egress_flood_mc)(struct dsa_switch *ds, int port, bool enable);
> 	int (*port_egress_flood_bc)(struct dsa_switch *ds, int port, bool enable);
> 
> rather than trying to combine uc/mc into one?  It would mean that we'd
> be performing more bus reads/writes, but I guess that doesn't matter
> for these configuration parameters.

I like this very much. As long as these flags can be programmed in switch
devices, these ops totally make sense.


Thanks,

	Vivien