[ovs-dev] [PATCH] support NXAST_SET_TUNNEL_DST action

Jesse Gross jesse at nicira.com
Tue Dec 11 02:42:56 UTC 2012


On Mon, Dec 10, 2012 at 5:16 PM, Rich Lane <rich.lane at bigswitch.com> wrote:
> This action allows the controller to change the destination IP of the
> encapsulating packet. It just exposes the existing Linux datapath
> functionality.
>
> Tested by installing a flow with the new action and an output action to a GRE
> tunnel port. The resulting packet had the correct destination IP.
>
> Signed-off-by: Rich Lane <rich.lane at bigswitch.com>

The immediate intention of the new infrastructure in the kernel module
was not actually to support this type of operation, it's primarily
designed to be consumed by userspace (and to futureproof the
interface).  As such, I don't think we can just expose it outwards
directly without fleshing out the concept.

The first and easiest piece is that the userspace/kernel interface
should be completely built out before we start adding pieces on top of
it.  In particular, it should support the receive side and also not
encode particular policies into the serialization layer.  I sent out a
patch to do this a while back.  I couldn't apply it at the time since
other pieces were missing (which have since been filled in) and
haven't had time to update it.  Here it is if you want to help get it
in:
http://openvswitch.org/pipermail/dev/2012-September/021548.html

Another issue is that this doesn't help on the receive side,
particularly because packets are matched to ports with their
associated IP addresses.  In general, I'm not sure that current port
configuration makes sense in this context.

Finally, the kernel interface was designed with the assumption that it
is operating in the context of an exact match flow, which is why it
contains actual values for things like ToS and TTL.  This enables
userspace to flexibly implement different policies like inheritance
but it makes less sense in the context of general OpenFlow flows.
There is a similar difference with how we implement decrement/set IP
TTL: in OpenFlow these are explicit actions but in the kernel
interface they both map to a single 'set' command since userspace can
calculate the right value.  I would expect to see a similar difference
in reverse here.



More information about the dev mailing list