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:

quoted

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

quoted

quoted

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.

quoted

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