netdev - Re: [PATCH v2.62] datapath: Add basic MPLS support to kernel

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:	Tue, 24 Jun 2014 16:24:37 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Simon Horman <horms@...ge.net.au>
Cc:	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	netdev <netdev@...r.kernel.org>, Ravi K <rkerur@...il.com>,
	Joe Stringer <joe@...d.net.nz>, Thomas Graf <tgraf@...g.ch>
Subject: Re: [PATCH v2.62] datapath: Add basic MPLS support to kernel

On Tue, Jun 24, 2014 at 4:56 AM, Simon Horman <horms@...ge.net.au> wrote:
> Allow datapath to recognize and extract MPLS labels into flow keys
> and execute actions which push, pop, and set labels on packets.
>
> Based heavily on work by Leo Alterman, Ravi K, Isaku Yamahata and Joe Stringer.
>
> Cc: Ravi K <rkerur@...il.com>
> Cc: Leo Alterman <lalterman@...ira.com>
> Cc: Isaku Yamahata <yamahata@...inux.co.jp>
> Cc: Joe Stringer <joe@...d.net.nz>
> Signed-off-by: Simon Horman <horms@...ge.net.au>

Applied, thanks for all your work. Time to break out the champagne :)

That being said, I do have a couple of comments for follow up discussion:
 * I removed the addition of MPLS to key_attr_size. This is trying to
calculate the maximum key size and since MPLS will never show up in
conjunction with IPv6 (the current longest key) and isn't longer than
it, MPLS shouldn't increase the maximum size.
 * I think there is a potential for MPLS packets to be incorrectly
offloaded on kernels 3.12-3.15 when encapsulated inside a tunnel. This
is because it won't hit either the OVS GSO code or your enhanced MPLS
feature check. I don't want to lose GSO for tunnels on those kernels
but maybe there is a way to avoid this potential problem without too
much work.
 * Maybe you can refresh my memory - in the case of a push_mpls after
pop_vlan, why can't we do this check correctly for at least one level
of vlan? It seems like we could use the inner EtherType to tell
whether an additional vlan tag is present.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html