Eric W. Biederman wrote:
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.
When NICs support that I guess they the macvlan driver could be adapted
to take advantage of that.
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.
It needs promiscous mode to learn, so I'm not sure how much
this will help bridging.
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.
Performance should be at least as good as on a bridge device since
the macvlan driver does basically nothing and uses the same functions
for receiving and sending packets.
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.
That doesn't happen under normal circumstances. I don't believe
it would work.
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.
It comes from the original code, I think it should be good enough.
-
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
