[ovs-dev] [PATCH] support NXAST_SET_TUNNEL_DST action

[Jesse Gross]

On Wed, Dec 12, 2012 at 11:08 PM, Jarno Rajahalme
<jarno.rajahalme at nsn.com> wrote:
> On Dec 13, 2012, at 8:22 , ext Rich Lane wrote:
> 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:
>> 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.

Yes, NULL ports definitely need to be created in some form here
although userspace doesn't currently do this.  The work that is
currently ongoing will essentially replicate the current kernel
behavior in userspace on top of the new flow infrastructure.  However,
this means that without some further work, you'll have the same
problems with packets being dropped before you see them because they
don't match.

I think the first step is to figure out what the external view of this
should be from the OpenFlow/configuration database level.  It might be
a version of NULL ports but then you have similar issues to the
kernel, where you don't know which datapath to map a packet on to.

> 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.
>
>
>
> Aren't we now with a single datapath? Does that make a difference here?

Yes, at the kernel level there is no mapping from tunnel IP
information to either port or datapath - it just extracts the
information and stores it in the flow.  This is why the single
datapath changes were necessary.

Almost everything in include/openvswitch/tunnel.h is going away since
it all relates to kernel port level configuration.  The only exception
is OVS_TUNNEL_ATTR_DST_PORT.

>> 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?
>
>
> I think Jesse meant the commit_* functions in odp-util.c when referring to
> the "serialization layer", if so all policy stuff should be above it.
> It seems that as part of figuring out the odp port in
> ofproto-dpif.c:compose_output_action__() we need to check if the odp port is
> a tunnel port and set the tunnel fields in the context accordingly. That
> seems like the proper place for tos inheritance processing as well.

Yes, that's right.  I have an early version of a patch to do these
types of manipulations here:
http://openvswitch.org/pipermail/dev/2012-September/021550.html

There's a lot of work in progress which is confusing things here.
Here's my original plan for all of this:
 1. Enable kernel to use flow-based tunneling. (done)
 2. Recreate existing functionality on top of new infrastructure. (in progress)
 3. Drop old kernel model.
 4. Build new functionality using the new infrastructure.

Right now we're talking about doing #4.  It might make more sense to
focus on #2 and #3 first so that we're just looking at a single set of
infrastructure and everything will be clearer.