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:   Thu, 02 Feb 2017 06:33:21 -0800
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     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,
        dsa@...ulusnetworks.com, hadi@...atatu.com
Subject: Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

On 2/1/17, 11:06 PM, Stephen Hemminger wrote:
> On Wed, 01 Feb 2017 21:58:25 -0800
> Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>
>> On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
>>> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>>>  
>>
[snip]

>>> I think most swith asics can do other tunnels too,
>>> so can this vlan->vxlan 1 to 1 be generalized to cover different
>>> types of tunnels that can be configured on the switch?  
>>
>> yes, it can be. Hence i have kept the tunnel info netlink attribute generic. similar to how LWT provides
>> various encaps at the L3 routing layer, this can provide such function at the L2 bridge layer. But, to keep it relatively lite I use the
>> already existing dst_metadata infra to bridge vlan to vxlan (Which is already done in the case of vxlan collect metadata mode.
>> I simply extend it to cover the bridge case).
>>
>> thanks,
> I wonder if this is a case for a new driver (with same subset of bridge API). You probably
> don't want all the baggage of STP, netfilter, VLAN filtering, etc when doing VXLAN VNI bridging.

We do want stp, netfilter, VLAN filtering, igmp snooping on the same bridge. In-fact this vlan-to-tunnel incremental feature I add here is only
available to the vlan filtering bridge.

It is in our best interest to make or keep the bridge driver suitable for all architectures. You have seen the bridge perf fixes from nikolay
recently, all those are towards the same effort. Nikolay has had a bunch of cleanup ideas and has been contributing patches to that effect.
 I think we should work on cleaning up and fixing the current bridge driver instead of introducing a new one. The bridge driver has a nice api which has been working great for various deployments...(like i mention, also for the hardware offload case).

If you have any performance numbers or data from other architectures, we would be happy to take a look and see what we can do more.