On Tue, Jan 15, 2013 at 3:32 PM, Ben Pfaff <[email protected]> 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. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
