netdev - Re: [RFC NET 00/02]: Secondary unicast address support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Jun 2007 14:31:53 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Patrick McHardy <kaber@...sh.net>
Cc:	netdev@...r.kernel.org, shemminger@...ux-foundation.org,
	davem@...emloft.net, jeff@...zik.org
Subject: Re: [RFC NET 00/02]: Secondary unicast address support

Patrick McHardy <kaber@...sh.net> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html