[ovs-dev] [PATCH] ofproto-dpif: Maintain tun_id across action lists.

Jesse Gross jesse at nicira.com
Wed Jan 16 00:12:38 UTC 2013

On Tue, Jan 15, 2013 at 3:32 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Tue, Jan 15, 2013 at 02:05:38PM -0800, Jesse Gross wrote:
>> Previously, a tunnel ID received on input would be used by default
>> on output if the packet was later sent out a tunnel.  This was not
>> actually intentional behavior - tunnel information is not supposed
>> to carry over.  However, it is useful in the case where move actions
>> are used to load the original tunnel ID into registers for further
>> processing since otherwise the information is lost before handling
>> actions.
> I don't think it's limited just to move actions: part of the bug report
> was that the original tun_id wasn't being retained for subsequent lookup
> in resubmits.  In other words, tracing a flow with initial tun_id of
> 0x1234 did a first-level flow lookup with that tun_id but it disappeared
> in the resubmit.  The report contained a lot of juggling around with
> move and load actions that touch tun_id (both as source and destination)
> but those really look like red herrings to me.
> I don't actually disagree with your analysis, I just think it's slightly
> more general than just move actions.

That's true, I updated the commit message to reflect that it also
applies to resubmits.

> This makes action_xlate_ctx_init() kind of hard to understand so a
> comment might be warranted.

I added a comment documenting behavior of the various transformations
(normal, VLAN splinters, and tunnels) and applied this to master.

More information about the dev mailing list