From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Subject: Re: [RFC PATCH net-next 0/3] Allow bridge to function in non-promisc mode Date: Thu, 07 Mar 2013 12:38:20 -0500 Message-ID: <5138D08C.8010307@redhat.com> References: <1362623485-18209-1-git-send-email-vyasevic@redhat.com> <5138B3C9.4060404@redhat.com> <20130307091340.6c5af4bb@nehalam.linuxnetplumber.net> Reply-To: vyasevic@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org To: Stephen Hemminger Return-path: In-Reply-To: <20130307091340.6c5af4bb@nehalam.linuxnetplumber.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bridge-bounces@lists.linux-foundation.org Errors-To: bridge-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org On 03/07/2013 12:13 PM, Stephen Hemminger wrote: > On Thu, 07 Mar 2013 10:35:37 -0500 > Vlad Yasevich wrote: > >> On 03/07/2013 02:19 AM, Stephen Hemminger wrote: >>> I understand the desire to add more functionality, but in this case it >>> would introduce lots more problems. STP would break and it doesn't seem to >>> gain anything that can't be done by other means. >>> >>> Turning bridge into macvlan seems unnecessary. Combining apples and bananas >>> doesn't always make a tasty smoothy, sometimes it is just a mess. >>> >>> Maybe adding a little more to macvlan to do what you want would be simpler. >>> >> >> >> It's not really a macvlan over the bridge. I would agree that >> particular setup would be a bit odd. This work enables VMs to manage >> their mac addresses and to reduce the load on the host by keeping the >> bridge in promisc mode. >> >> Sadly, most kvm network configs still use bridging and have not >> transitioned to OVS. macvlan has some limitations as well and I working >> to address those, but there is a desire for non-promisc bridge. In >> this case VMs can manage their mac addresses and can write that data to >> the bridge. >> >> STP is not broken as STP uses multicast mac and we set IFF_ALLMULTI thus >> continuing to receive and process STP BPDUs. >> >> The one thing that would appear to suffer from this is VLAN reception, >> but the bridge does allow vlan config now and that would have to be >> configured if VMs wish to use vlans. >> >> I am not changing default operation of the bridge. Default is still >> promisc. In fact, one can switch back and forth without any network >> outages. This simply adds another mode the the bridge operation. >> > > 1. I am not a fan of the added complexity. > 2, Don't use sysfs for new API's use netlink instead. Oh, I had a question for you about this. I am changing the uplink code slightly to pattern more after some of the security features you added (like root_block and bpdu_guard). I makes things simpler. I would really like to provide the sysfs interface, because I checked iproute code and I don't see any netlink implementation of those things. Would that be more agreeable to you? Thanks -vlad I > 3. It depends on the uplink port providing UNICAST filtering which some > physical devices don't do. >