Patrick McHardy <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> I'm trying to understand what the point of this patch is. >> >> In once sense I find the concept of filtering and listening for multiple >> mac addresses very interesting, especially if we could break out different >> streams of traffic by destination mac address into separate network devices. >> This would remove the need to any kind of ethernet tunnel and makes multiple >> network namespaces much more pleasant. >> >> However this just seems to allow a card to decode multiple mac addresses >> which in some oddball load balancing configurations may actually be >> useful, but it seems fairly limited. >> >> Do you have a specific use case you envision for this multiple mac >> functionality? >> > > Yes, please see the MACVLAN patch I posted one or two days earlier.
Thanks. That is what I was envisioning. I keep suspecting one of the cool multi-rx queue nics my start doing some of the demux in hardware. But whatever if it works and is relatively fast it is good enough for me. > 8021q can also make use of it and Dave mentioned some virtualization > devices want this as well. Right makes sense. And ethernet bridging (which is the general case of the virtualization Dave mentioned should also be able to take advantage of multiple unicast addresses). So this definitely make sense. Have you done any performance testing with the macvlan code? With the ethernet tunnel device we keep getting copied unicast packets on some path or other which slowed things down. Simply not doing the firewalling until the packets have made it through the macvlan device should help here. For the macvlan code do we need to do anything special if we transmit to a mac we would normally receive? Another unicast mac of the same nic for example. For the macvlan hash you just use an upper byte. Is that just a simple starting place, or do we not need a more complex hash. Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
