[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190219132008.GB16594@t480s.localdomain>
Date: Tue, 19 Feb 2019 13:20:08 -0500
From: Vivien Didelot <vivien.didelot@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>,
Andrew Lunn <andrew@...n.ch>,
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 Florian,
On Tue, 19 Feb 2019 09:44:32 -0800, Florian Fainelli <f.fainelli@...il.com> wrote:
> > 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.
>
> I am not sure if it makes sense for us to work hard on supporting
> BR_BCAST_FLOOD, for instance, on Broadcom switches, there does not
> appear to be an easy way to specify whether broadcast traffic will be
> flooded or not, it will be. The only way to tsolve that is to create a
> MDB/FDB entry with negative logic (e.g.: forward to a
> non-existing/connected port). Every other bridge flag typically maps 1:1
> with a corresponding hardware feature, so we should support them.
I think it's best to keep away from driver-specific hacks :-)
Since broadcom floods multicast and BR_BCAST_FLOOD is set by default,
this would simply translate as not implementing a port_flood_bc ops in the
broadcom driver.
But I agree that it doesn't seem necessary to implement support for this yet.
Thanks,
Vivien
Powered by blists - more mailing lists