From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <5140B1B3.2070205@redhat.com> Date: Wed, 13 Mar 2013 13:04:51 -0400 From: Vlad Yasevich MIME-Version: 1.0 References: <1363139126-13396-1-git-send-email-vyasevic@redhat.com> <473541363155743@web2d.yandex.ru> <51406D2D.30703@redhat.com> <20130313083932.6483876f@nehalam.linuxnetplumber.net> <51409F24.3070305@redhat.com> <20130313090921.05dbf6e2@nehalam.linuxnetplumber.net> In-Reply-To: <20130313090921.05dbf6e2@nehalam.linuxnetplumber.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH net-next 0/4] Allow bridge to function in non-promisc mode Reply-To: vyasevic@redhat.com List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stephen Hemminger Cc: "netdev@vger.kernel.org" , "bridge@lists.linux-foundation.org" , "Oleg A. Arkhangelsky" On 03/13/2013 12:09 PM, Stephen Hemminger wrote: > On Wed, 13 Mar 2013 11:45:40 -0400 > Vlad Yasevich wrote: > >> On 03/13/2013 11:39 AM, Stephen Hemminger wrote: >>> On Wed, 13 Mar 2013 08:12:29 -0400 >>> Vlad Yasevich wrote: >>> >>>> On 03/13/2013 02:22 AM, "Oleg A. Arkhangelsky" wrote: >>>>> >>>>> >>>>> 13.03.2013, 05:45, "Vlad Yasevich" : >>>>> >>>>>> The series adds an ability for the bridge to function in non-promiscuous mode. >>>>> >>>>> What is the practical applications for such setup? In other words, >>>>> in which cases I would want to put bridge into non-promiscuous >>>>> mode and specify some uplink ports? >>>>> >>>> >>>> On of the applications would be when bridge is an edge device servicing >>>> a VM deployment. Each of the VMs knows the mac address that the guest >>>> has and may program that mac onto the uplinks. >>> >>> Why wouldn't that environment just use macvlan? >>> Is it because changing libvirt is harder than changing the kernel? >>> >> >> No, because macvlan has a drawback that it doesn't easily let guests >> talk to the host. Bridge is still most commonly used for just that reason. >> >> -vlad > > Maybe fixing that with a flag to macvlan would be easier? > Not really. macvlan to physical device could be made simple enough. However, physical to macvlan is non-trivial at all. We get around this right now by crating a macvlan on the host and have macvlan to macvlan communication essentially turning it into bridge. But that doesn't work in all scenarios either. -vlad