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

Thomas Graf [off-list ref] 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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev