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 20:50:53 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     roopa@...ulusnetworks.com
Cc:     netdev@...r.kernel.org, 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

I see a lot of "complexity of bridging layer" pushback on these
changes, and I understand where that is coming from.

But really this isn't even, at a high level, really a bridging change.

What it's doing is making lwtunnel objects more useful.

Now that we have lightweight tunnels and netdevs, we will constantly
have this struggle trying to figure out how to make lwtunnel objects
apply to the same cases that netdevs currently only work for.

Because once you run into one of these situations where only netdevs
work, you are screwed and lwtunnels and their scalability benefit
might as well not even exist.

To be completely honest, in this case it's pretty clear:

1) It makes vxlan lwtunnel objects more usable for bridges.

2) It does not make lwtunnels more bloated or consume more memory
   or cpu in the dataplane fast paths.

3) It makes uptake of lwtunnels higher, because they can be used
   in more places.

So I think this change is a win and a move forward.