netdev - Re: [net-next RFC 00/14] Convert OVS tunnel vports to use regular net

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]

Message-ID: <87a8wiszln.fsf@x220.int.ebiederm.org>
Date:	Tue, 02 Jun 2015 14:02:28 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Thomas Graf <tgraf@...g.ch>
Cc:	netdev@...r.kernel.org, pshelar@...ira.com, jesse@...ira.com,
	davem@...emloft.net, daniel@...earbox.net, dev@...nvswitch.org,
	tom@...bertland.com, edumazet@...gle.com, jiri@...nulli.us,
	hannes@...essinduktion.org, marcelo.leitner@...il.com,
	stephen@...workplumber.org, jpettit@...ira.com, kaber@...sh.net,
	Robert Shearman <rshearma@...cade.com>,
	roopa <roopa@...ulusnetworks.com>
Subject: Re: [net-next RFC 00/14] Convert OVS tunnel vports to use regular net_devices

Thomas Graf <tgraf@...g.ch> writes:

> This is the first series in a greater effort to bring the scalability
> and programmability advantages of OVS to the rest of the network
> stack and to get rid of as much OVS specific code as possible.
>
> This first series focuses on getting rid of OVS tunnel vports and use
> regular tunnel net_devices instead. As part of this effort, the
> routing subsystem is extended with support for flow based tunneling.
> In this new tunneling mode, the route is able to match on tunnel
> information as well as set tunnel encapsulation parameters per route.
> This allows to perform L3 forwarding for a large number of tunnel
> endpoints and virtual networks using a single tunnel net_device.

This is a different direction than I was imagining things evolving when
I was looking at mpls.  However there is a lot of overlap.

I get the imperession there are two directions you are looking at:
- Allowing more configurable keeps in route based lookup.
- Reducing the costs of the tunnels.

We already have a similar subsystem xfrm.

If we are going to use more flexible keys when lookup up routes, if it
is reasonably possible (while maintaining performance) I suggest we use
the xfrm data structure or more likely rework xfrm on top of the new
data structures.  That way there is less code to maintain overall.

Certainly any work that plays with tunnels a new way to do tunnels in
the kernel needs to answer the question.  Why not xfrm.  As xfrm already
exists to do exactly that job.

I think a clumsy api and excess flexibility start to be an answer for
mpls ingress.  Just using the existing routing table can result in
cleaner faster code with a better userspace API.  But I still think the
mpls case where we attach labels needs to answer that case.

If you are using flow based flexibility from openvswitch I think why not
use xfrm becomes a more challenge question to answer.

Eric
--
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