Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux