On Wed, Sep 19, 2012 at 4:04 PM, Kyle Mestery (kmestery) <kmest...@cisco.com> wrote: > On Sep 19, 2012, at 1:59 PM, Jesse Gross wrote: >> There's been quite a bit of interest in plans for getting tunneling >> upstream and supporting VXLAN. Since I know that both end users and >> developers are curious I thought that I would send out the current >> plan for making this happen. If anyone has comments or suggestions on >> the plan, please let me know. >> >> The reason why tunneling wasn't submitted upstream together with the >> rest of the kernel code is because the userspace/kernel interfaces as >> they exist today aren't sufficiently future-proof that we would want >> to freeze them. An example of where they break down is with VXLAN >> multicast learning since it's necessary to be able to discover new >> tunnel endpoints dynamically. It would be possible to implement this >> entirely in the kernel but userspace has a much richer set of >> information and it's preferable to move complexity there anyways. As >> a result, the idea is to give userspace control over the tunnel >> headers on a per-flow basis which it can use to implement the existing >> tunnel ports, VXLAN learning, and likely more sophisticated controls >> through OpenFlow in the future. With that in place we can quickly >> push tunneling upstream and add support for VXLAN. >> >> Here are the rough components: >> >> OVS kernel module (Kyle) - Add support for matching and setting tunnel >> outer headers via flows. >> >> Upstream tunnel abstraction (Pravin) - Currently there are a number of >> tunnel implementations upstream with both a control plane for talking >> to userspace, maintaining devices, etc. and a data plane for the >> actual protocol handling. My hope is that we can abstract the control >> planes out into common code that drive the various data plane >> implementations. Once that happens OVS can become an alternate >> control plane using the same data plane implementations. >> >> Decouple userspace ports from kernel (Justin) - To maintain current >> tunnel port abstractions userspace will need to have a notion of ports >> and datapaths that no longer maps directly to that of the kernel since >> tunnel ports will be backed entirely by flows. >> >> Port tunnel code from kernel to userspace (Jesse) - One of the >> benefits of this approach is that much of the current tunnel code in >> the kernel can now be implemented in userspace in such a way that is >> both simpler and happens on a per-flow basis rather than per-packet. >> >> VXLAN implementation - Once the above components are in, the existing >> VXLAN patch (plus optional use of a multicast control plane) can be >> updated to support the new model and integrated. >> >> The names that I listed above are just based on people who have >> expressed interest in doing the work. If you would like to help out >> let me know and we can find a project. > > This looks great to me Jesse, thanks for sending out this note. I was going > to send an email asking about the strategy, so your timing was perfect. > > I'm in the bay area this week, but plan to pickup item #1 above and hope > to finish it next week to keep the ball rolling on this work.
Thanks for the update. I'm making good progress on porting the kernel tunneling logic to userspace and it's coming out nicely so I think that we'll be able to get things in pretty quickly. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
