Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Simon Horman <hidden>
Date: 2012-04-26 07:13:21
On Wed, Apr 25, 2012 at 10:17:25AM -0700, Jesse Gross wrote:
On Wed, Apr 25, 2012 at 1:39 AM, Simon Horman [off-list ref] wrote:quoted
Hi Kyle, the component that is of most interest to me is enabling OVS to use in-tree tunnelling code - as it seems that makes most sense for an implementation of STT. I have taken a brief look over your vxlan work and it isn't clear to me if it is moving towards being an in-tree implementation. Moreover, I'm a rather unclear on what changes need to be made to OVS in order for in-tree tunneling to be used. My recollection is that OVS did make use of in-tree tunnelling code but this was removed in favour of the current implementation for various reasons (performance being one IIRC). I gather that revisiting in-tree tunnelling won't revisit the previous set of problems. But I'm unclear how. Jesse, is it possible for you to describe that in a little detail or point me to some information?This was what I had originally written a while back, although it's more about OVS internally and less about how to connect to the in-tree code: http://openvswitch.org/pipermail/dev/2012-February/014779.html In order to flexibly implement support for current and future tunnel protocols OVS needs to be able to get/set information about the outer tunnel header when processing the inner packet. At the very least this is src/dst IP addresses and the key/ID/VNI/etc. In the upstream tunnel implementations those are implicitly encoded in the device that sends or receives the packet. However, this has a two problems: number of devices and ability to handle unknown values. We addressed part of this problem by allowing the tunnel ID to be set and matched through the OVS flow table and an action. In order to do this with the in-tree tunneling code, we obviously need a way of passing this information around since it would currently get lost as we pass through the Linux device layer. The plan to deal with that is to add a function to the in-tree tunneling code that allows a skb to be encapsulated with specific parameters and conversely a hook to receive decapsulated packets along with header info. This would make all of the kernel tunneling code common, while still giving OVS userspace the ability to implement essentially any type of tunneling policy. In many ways, this is very similar to how vlans look in OVS today. While it would be possible to implement the hook to use the in-tree tunnel code today without a lot of changes, we already know that we want to move away from port-based model in the OVS kernel module towards the flow model. As we push this upstream the userspace/kernel API should be the correct one, so that's why these two things are tied together.
Thanks, that explanation along with Kyle's response helps a lot. It seems to me that something I could help out with is the implementation of the set_tunnel action which extents and replaces the tun_id action. It seems that is a requirement for the scheme you describe above. http://openvswitch.org/pipermail/dev/2012-April/016239.html _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev