netdev - Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode

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]

Message-ID: <4F843544.8060209@intel.com>
Date:	Tue, 10 Apr 2012 06:27:32 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
CC:	roprabhu@...co.com, stephen.hemminger@...tta.com,
	davem@...emloft.net, hadi@...erus.ca, bhutchings@...arflare.com,
	jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org,
	gregory.v.rose@...el.com, krkumar2@...ibm.com, sri@...ibm.com
Subject: Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan
 mode

On 4/10/2012 1:09 AM, Michael S. Tsirkin wrote:
> On Mon, Apr 09, 2012 at 03:00:54PM -0700, John Fastabend wrote:
>> This adds a new macvlan mode MACVLAN_PASSTHRU_NOPROMISC
>> this mode acts the same as the original passthru mode _except_
>> it does not set promiscuous mode on the lowerdev. Because the
>> lowerdev is not put in promiscuous mode any unicast or multicast
>> addresses the device should receive must be explicitely added
>> with the FDB bridge ops. In many use cases the management stack
>> will know the mac addresses needed (maybe negotiated via EVB/VDP)
>> or may require only receiving known "good" mac addresses. This
>> mode with the FDB ops supports this usage model.
> 
> 
> Looks good to me. Some questions below:
> 
>> This patch is a result of Roopa Prabhu's work. Follow up
>> patches are needed for VEPA and VEB macvlan modes.
> 
> And bridge too?
> 

Yes I called this mode VEB here but this is defined in if_link.h
as IFLA_MACVLAN_MODE_BRIDGE. From a IEEE point of view I think
the macvlan bridge mode acts more like a 802.1Q VEB then a 802.1d
bridge.

> Also, my understanding is that other modes won't need a flag
> like this since they don't put the device in promisc mode initially,
> so no assumptions are broken if we require all addresses
> to be declared, right?
> 

correct. But requires extra work to the hash table so the forwarding
works correctly.

> A final question: I think we'll later add a macvlan mode
> that does not flood all multicasts. This would change behaviour
> in an incompatible way so we'll probably need yet another
> flag. Would it make sense to combine this functionality
> with nopromisc so we have less modes to support?
> 

For VEPA and bridge modes this makes sense to me. If you want
the flood behavior you can create it by adding the addr to all
the devices or just to a subset of them to get the non-flooding
capabilities.

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