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 kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
