On 2/19/15, 6:03 PM, Florian Fainelli wrote:

On 19/02/15 16:09, Guenter Roeck wrote:

quoted

On Thu, Feb 19, 2015 at 03:50:53PM -0800, Florian Fainelli wrote:

quoted

On 19/02/15 09:46, Guenter Roeck wrote:

quoted

On Thu, Feb 19, 2015 at 09:27:23AM -0800, Florian Fainelli wrote:

quoted

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 ?

This is a real problem, for once I was working under the assumption that
the SF2 hardware was doing an automatic FDB flushing, but after
re-reading the documentation, this is not the case. My lab network does
not have many stations and I certainly did not catch that case.

The rocker code implements the fdb flush operation pretty much the same
way I do, so I seem to be doing something right.

Not sure yet what to do about setting the fdb aging time. I don't see a
mechanism to do that. No idea how important that is.

I think we'll also need support for ndo_vlan_rx_add_vid, ndo_vlan_rx_kill_vid,
ndo_fdb_add, ndo_fdb_del, and ndo_fdb_dump. Have you thought about those ?

Yes, we will need those as well, although for now, I think we might just
be able to get basic HW bridging to work with the current patches +
driver specific FDB flushing, what do you think?

The only part thing that I cannot really map to HW switches today is
that the ndo_vlan_rx_add_vid() does not specify whether the VLAN id you
are adding is tagged or untagged (aka native). You can configure that
using the "bridge" sub-command from iproute2, but I am not sure how this
translates in terms of programming the hardware with the tagged/untagged
bit yet.

Maybe we should update ndo_vlan_rx_add_vid() to allow for a tag bit to
specified?

You should be able to use switchdev api 
netdev_switch_port_bridge_setlink/dellink that in turn calls 
ndo_bridge_setlink/dellink for this.
PF_BRIDGE dellink/setlink calls from the user for vlan add/dels are 
mapped to these ndos. These include the vlan tagged/untagged/pvid flags.
(IFLA_BRIDGE_VLAN_INFO which is of type struct  bridge_vlan_info).
But note that these are only available with the vlan filtering bridge.