[ovs-dev] [PATCH] support NXAST_SET_TUNNEL_DST action

[Rich Lane]

On Mon, Dec 10, 2012 at 6:42 PM, Jesse Gross <jesse at nicira.com> wrote:

> 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
>

I'm assuming Jarno's ODP patch will be updated and merged. Jarno, please
let me know if you don't have time for this and I'd be happy to help.


> 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.
>

I thought the "null_port" change in the kernel datapath already allowed
packets from any remote IP to match, if userspace didn't
supply OVS_TUNNEL_ATTR_DST_IPV4 when creating the tunnel port. Or do you
mean that we should remove OVS_TUNNEL_ATTR_* entirely now? I'd think you'd
want to do that last, after all the flow-based tunneling patches are merged.

The OVS_TUNNEL_ATTR_SRC_IPV4 configuration or equivalent would still need
to exist for flow-based tunneling, right? If there are multiple datapaths
and each one has a tunnel port we need some way to choose between them.

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.
>

Are you saying we need to move the handling of flags like TNL_F_TOS_INHERIT
into commit_set_tunnel_action in userspace?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20121212/cf129d3c/attachment-0003.html>