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  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

Powered by blists - more mailing lists