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, 5 Mar 2012 18:00:44 +0100
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	John Fastabend <john.r.fastabend@...el.com>,
	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 Thu, Mar 01, 2012 at 08:36:20AM -0500, Jamal Hadi Salim wrote:

> > > I want to see a unified API so that user space control applications (RSTP, TRILL?)
> > > can use one set of netlink calls for both software bridge and hardware offloaded
> > > bridges.  Does this proposal meet that requirement?
> > > 
> 
> I dont see any issues with those requirements being met.
> 
> > Jamal, so why do "They have to be different calls"? I'm not so sure anymore...
> > moving to RTM_FDB_XXXENTRY saved some refactoring in the bridge module but that
> > is just cosmetic.
> 
> I may not want to use the s/ware bridge i.e I may want to use h/ware
> bridge. I may want to use both.

This is a rather common case in embedded wireless routers/access points,
where you want to have the 4 LAN ports bridged together with the wlan0
interface.

In this scenario, the bridging between the LAN ports is typically done
in hardware, and the bridging between the LAN ports and wlan0 in
software, but here you have to be careful when you send the packet from
the switch chip up the stack to be forwarded to the wlan0 interface to
not re-send it to the hardware switch chip ports other than the one
that the packet came from.

net/dsa currently solves this by not having the hardware handle
broadcast packets at all, which circumvents the problem, but for
multicast traffic you would still like to be able to do at least the
forwarding that can be done in hardware in hardware.  (Unicast doesn't
have this problem as long as the kernel and the switch chip agree on
their view of the FDB.)
--
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