On Tue, 2012-03-06 at 15:09 +0100, Lennert Buytenhek 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. > > 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. > It does, there is an STP state field per port in the switch chip, > which controls whether learning takes place on this port (in > Learning and Forwarding states) and whether packets are forwarded > (in the Forwarding state). ok, makes sense. > But e.g. it doesn't automatically flush this port's FDB entries if > you move a port from Forwarding to Listening -- the STP state field > only controls direct learning and forwarding for received packets. > > And when you receive a BPDU with the topology change notification > bit set, the switch won't automatically shorten the FDB entry > timeout for you until the topology change is over, either. I have to go back and look at some manuals i have - but iirc, the ones ive played with behaved similarly. As long as we provide knobs to set/unset those different attributes, I think the handling of all that should be from software (likely some daemon in user space); then it shouldnt matter whether we are working with STP BPDUs or TRILL or thenewprotocolTM etc. > 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? 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. > You can let the switch rate limit the number of packets passed up to > the CPU. 500 kp/s broadcast traffic seems somewhat excessive in any > case, and I'm not sure if this deserves handling apart from QoSing > those streams to manageable levels. Yes, that would provide a solution. I havent seen anything where you can rate limit the learning(SA lookup failure). cheers, jamal -- 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
