Thread (65 messages) 65 messages, 8 authors, 2015-03-04

Re: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations

From: Guenter Roeck <linux@roeck-us.net>
Date: 2015-02-19 17:46:45

On Thu, Feb 19, 2015 at 09:27:23AM -0800, Florian Fainelli wrote:
On 18/02/15 21:59, Guenter Roeck wrote:
quoted
On Wed, Feb 18, 2015 at 06:48:19PM -0800, Florian Fainelli wrote:
quoted
On 17/02/15 11:26, Florian Fainelli wrote:
quoted
Update the Broadcom Starfighter 2 switch driver to implement the
join/leave/stp_update callbacks required for basic hardware bridging
support.

There is not much to be done at the driver level but translating the
STP state from Linux to their HW values.

Joining a bridge means that the joining port and the other port members
need to be in the same VLAN membership as the CPU, while leaving the
bridge puts the port back into a separate VLAN membership with only the
CPU.
I found a couple additional issues while testing:

- manipulating UP/DOWN state of interfaces that are part of a bridge
would not restore their bridge membership

- removing an interface from a bridge and bringing it back up would
leave it in blocked state
Is this a problem with your implementation for sf2 or a generic problem
with the first patch, such as some missing state transitions ?
This is more of a side effect of having HW (an Ethernet switch) that can
really block a given port, based on last night's discussion with Roopa,
we can either fix this at the DSA level (in our case) or better fix this
at the bridge layer, I will propose a fix for this shortly.
quoted
For sf2, you might have to set the port state as well as the bridge
association in the port_setup function. That is of course just a
wild guess.
Right, that's what I ended up doing. Thanks!
Great.

Another question: How do you handle flushing the forwarding database ?

My current code for mv88e6352 flushes the forwarding database for a bridge
group if the port association for that group changes (whenever a port joins
or leaves a group, or whenever the state of a port in a group changes).
There is, however, another situation where the forwarding database may
have to be flushed - essentially on each topology change.

How do you handle this situation ? Is it a real problem or do I just
imagine that it is ?

Thanks,
Guenter
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help