Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

[John Fastabend <john.r.fastabend@intel.com>]

On 3/5/2012 8:53 AM, Lennert Buytenhek wrote:
> On Tue, Feb 28, 2012 at 08:40:06PM -0800, John Fastabend wrote:
> 
>> Also if there are embedded switches with learning capabilities they
>> might want to trigger events to user space. In this case having
>> a protocol type makes user space a bit easier to manage. I've
>> added Lennert so maybe he can comment I think the Marvell chipsets
>> might support something along these lines. The SR-IOV chipsets I'm
>> aware of _today_ don't do learning. Learning makes the event model
>> more plausible.
> 
> net/dsa currently configures any switch chips in the system to do
> auto-learning.  However, I would much prefer to disable that, and have
> the switch chip just pass up packets for new source addresses, have
> Linux do the learning, and then mirror the Linux software FDB into
> the hardware instead -- that avoids having to manually flush the
> hardware FDB on certain STP state transitions or having to configure
> the hardware to use a shorter address learning timeout when we're in
> the middle of an STP topology change, which are problems we are
> running into in practice.
> 

Great. And the plan is we should be able to use the same daemon with
minimal changes (currently a flag) to control both sw and hw bridges.

> Just curious -- while your patches allow propagating FDB entries
> into the hardware, do you also have hooks to tell the hardware which
> ports are to share address databases?
> 

Not in the current patches. I don't have hardware right now
that can instantiate multiple bridges. When I get some I was hoping
to do something similar to this patch and use netlink commands
to create/delete bridges and add/remove ports to them. This would
be modifying the existing commands to work for both software and
hardware bridges.

By a bridge instantiation I mean a shared address database in this case.

> For net/dsa, we currently have:
> 
> 	http://patchwork.ozlabs.org/patch/16578/
> 
> While I think this is conceptually sound, the implementation is hacky,
> and I wonder how you've solved it for your setup, and if DSA can
> piggy-back off that.

Yep anything we come up with should work in both cases.