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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190219120000.GB4140@t480s.localdomain>
Date:   Tue, 19 Feb 2019 12:00:00 -0500
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for
 bridge flags

Hi Russell,

On Tue, 19 Feb 2019 16:24:35 +0000, Russell King - ARM Linux admin <linux@...linux.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?

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.

Thanks,

	Vivien