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: <20120312084850.GB28523@wantstofly.org>
Date:	Mon, 12 Mar 2012 09:48:50 +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 Wed, Mar 07, 2012 at 09:11:40AM -0500, Jamal Hadi Salim wrote:

> > Why so?  (I think the switch chips should just never do learning at
> > all..)
> 
> I agree that learning in software gives you more flexibility;
> however, I am for providing interface flexibility as well - switches
> have learning features. I think i should be able to use them when it
> makes sense to. 

Since it can lead to problems (address database mismatches, doesn't
correctly handle STP transitions or topology changes automatically),
I think it should be avoided whenever possible.  I don't see any
advantages of hardware based learning over software based learning
anyway ('flexibility' doesn't seem like a very good argument).


> > > I think it should also be upto the admin to decide whether the
> > > learning happens in the kernel or user space.
> > 
> > I can't see any point in doing it in userspace.  What would be the
> > advantage of that?  And based on what would the admin make the decision?
> 
> If i wanted to do some funky access control based on some new MAC
> address showing up - best place to do it is user space.

Alright, that sounds fair.


> > Keep in mind that these chips also do VLAN tagging in hardware, and
> > so a scenario like:
> > 
> > 	# brctl addbr br123
> > 	# brctl addif br123 lan1.123
> > 	# brctl addif br123 lan2.123
> > 
> > is also one that can be handled in hardware (which the current
> > patchwork patch doesn't handle yet).
> 
> We would need to work with offloading VLANs, no?

Yes.


> Do the current VLAN offloads used for NICs suffice for switching
> chips as well?  i.e typically most chips have a table associated
> with some port in which the Vlan is partof or is the lookup key. 

It should be doable along the lines of the current DSA patch --
add a VLAN ID argument to the interface add/remove callbacks, and
when a VLAN virtual interface is added to the bridge, call the
relevant callbacks with the parent interface + VLAN ID instead.
(This doesn't work for stacked VLANs, but the current net/dsa
supported chips don't handle those anyway.)
--
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