netdev - Re: [PATCH net-next v2 0/5] bridge: per vlan dst

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]

Date:   Wed, 01 Feb 2017 21:07:56 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     David Ahern <dsa@...ulusnetworks.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        netdev@...r.kernel.org, davem@...emloft.net,
        nikolay@...ulusnetworks.com, tgraf@...g.ch,
        hannes@...essinduktion.org, jbenc@...hat.com, pshelar@....org,
        hadi@...atatu.com
Subject: Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

On 2/1/17, 8:04 PM, Stephen Hemminger wrote:
> On Wed, 01 Feb 2017 20:02:35 -0800
> Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>
>> On 2/1/17, 5:59 PM, David Ahern wrote:
>>> On 2/1/17 6:23 PM, Alexei Starovoitov wrote:  
>>>> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:  
>>>>>                     
>>>>> This provides the required vxlan bridging function but poses a
>>>>> scalability problem with using a separate vxlan netdev for each vni.  
>>>> if I remember correctly this issue was the main reason David Ahern
>>>> put netdev on diet. Sounds like no more fun at netconf ;)
>>>>  
>>> oh, it still needs a diet ...  
>>  Even if the netdev went on diet, a netdev per vni for vxlan deployments is just too much overhead.
>>
>>
> But the intent was VNI == VLAN tag and there are cases where you need per VNI rules.
what rules are these ?
> Having them all smashed into one netdev seems like a step in the wrong direction.
only thing that a vxlan netdev per vni carries is a separate fdb table per vni with mac as the key. The natural progression from one fdb table per vni to a single fdb table for all vni's is to support a fdb table with  <mac, vni> as the key. So, unclear why it is a step in the wrong direction. This is exactly how the vlan filtering bridge fdb table is built also ...with <mac, vlan> as the key.

And, note that a single vxlan netdev is already deployed in COLLECT_METADATA mode. This series, just makes the fdb
available to the single vxlan netdev in COLLECT_METADATA mode. No change to the normal default mode of one vxlan netdev per vni.