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]

Message-ID: <20120306141551.GB27559@wantstofly.org>
Date:	Tue, 6 Mar 2012 15:15:51 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	John Fastabend <john.r.fastabend@...el.com>
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 Mon, Mar 05, 2012 at 07:45:22PM -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.

Why should userspace care at all whether there is a hw bridge present?


> > 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.

In the DSA h/w bridging patch, a hardware address database is only
allocated on addif to an existing bridge, not on addbr.

For one, at addbr time, you have no idea yet whether there will
be any switch chip ports in the bridge port group for this bridge.

Also, the h/w has some restrictions on the assignment of address
database identifiers (e.g. if you want to bridge between lan1.123
and lan2.123, you have to use address database identifier '123').


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

Makes sense.  (I'd add STP port states to this.)
--
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