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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 19 Feb 2015 16:51:30 -0800
From:	roopa <>
To:	Guenter Roeck <>
CC:	Florian Fainelli <>,,,,,,
Subject: Re: [PATCH RFC 2/2] net: dsa: bcm_sf2: implement HW bridging operations

On 2/19/15, 4:09 PM, Guenter Roeck wrote:
> On Thu, Feb 19, 2015 at 03:50:53PM -0800, Florian Fainelli wrote:
>> On 19/02/15 09:46, Guenter Roeck wrote:
>>> On Thu, Feb 19, 2015 at 09:27:23AM -0800, Florian Fainelli wrote:
>>>> On 18/02/15 21:59, Guenter Roeck wrote:
>>>>> On Wed, Feb 18, 2015 at 06:48:19PM -0800, Florian Fainelli wrote:
>>>>>> On 17/02/15 11:26, Florian Fainelli wrote:
>>>>>>> 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.
>>>>> 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.
rocker, the only consumer today relies on the bridge driver aging of 
learnt entries.
You could do the same.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists