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

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 05 Mar 2012 19:45:22 -0800
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
CC:	jhs@...atatu.com, jamal <hadi@...erus.ca>,
	Stephen Hemminger <shemminger@...tta.com>,
	bhutchings@...arflare.com, roprabhu@...co.com,
	netdev@...r.kernel.org, mst@...hat.com, chrisw@...hat.com,
	davem@...emloft.net, gregory.v.rose@...el.com, kvm@...r.kernel.org,
	sri@...ibm.com, Chris Healy <chealy@...co-us.com>
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html