Thomas Graf <tg...@suug.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
