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, 1 Feb 2017 17:23:03 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        stephen@...workplumber.org, 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 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 ;)

> Solution in this patch series:
> The Goal is to use a single vxlan device to carry all vnis similar
> to the vxlan collect metadata mode but additionally allowing the bridge
> and vxlan driver to carry all the forwarding information and also learn.
> This implementation uses the existing dst_metadata infrastructure to map
> vlan to a tunnel id.

ovs and/or bpf can do the same already, but sounds like the main reason is
to keep it integrated with bridge fdb to leverage your offload of bridge
fdb into hw asic, right?
If so, I guess, the extra complexity can be justified.
The question is how do you program hw ? Is there really 1 to 1 mapping
in the asics too? Or is it more flexible ?
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?