Re: [Bridge] [RFC PATCH net-next 0/3] Allow bridge to function in non-promisc mode

[Vlad Yasevich <vyasevic@redhat.com>]

On 03/07/2013 12:13 PM, Stephen Hemminger wrote:
> On Thu, 07 Mar 2013 10:35:37 -0500
> Vlad Yasevich <vyasevic@redhat.com> 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.
>