[ovs-dev] [PATCH 1/2] Add support for tun_key to OVS datapath

Jesse Gross jesse at nicira.com
Thu Oct 4 20:26:41 UTC 2012

On Thu, Oct 4, 2012 at 1:12 PM, Kyle Mestery (kmestery)
<kmestery at cisco.com> wrote:
> On Oct 3, 2012, at 11:38 AM, Jesse Gross wrote:
>> Also, when I was working on the userspace portions I defined three
>> flags to be used instead of the current tunnel port configuration:
>> Flow lib/flow.h:
>> #define FLOW_TNL_F_DONT_FRAGMENT (1 << 0)
>> #define FLOW_TNL_F_CSUM (1 << 1)
>> #define FLOW_TNL_F_KEY (1 << 2)
>> Can you add these to the kernel header and allow them to control
>> encapsulation/decapsulation?  This was one of the main blockers that I
>> ran into when doing the userspace work.
> Jesse, just to clarify, for this you mean modify the pieces in tunnel.c where
> it's using this configuration (similar flags) from the tunnel itself, and instead
> make the code use the values from the tun_key, right? If we do this, won't
> this be a tipping point which will break backwards compatibility? How should
> we proceed here, just use the values from tun_key only, or do you want me
> to provide compatibility with both until your changes come in?

I think we can do it in a way that provides compatibility with both at
the same time.  If a OVS_KEY_ATTR_IPV4_TUNNEL action was used to
transmit to the tunnel (in other words, ipv4_dst != 0) then we can
assume that we're in the new mode and directly use the flags,
overriding whatever options are set on the tunnel.  Otherwise, we can
use the config as we currently do.  On receive, we can always supply
the information.

More information about the dev mailing list