[ovs-dev] Q on supporting actions with no arguments

[Jesse Gross]

On Tue, Feb 7, 2012 at 3:57 PM,  <Ravi.Kerur at telekom.com> wrote:
> Hi,
>
> I am working on implementing mpls functionality into ovs. In the past I have
> had discussions with Ben for suggestions/inputs. We thought it would be good
> to send it to ovs-dev on debugging issues. Code development (control path,
> user-space and kernel-space datapath) is complete.
>
> So far, I am able to get some mpls actions(push, pop, setting mpls_label,
> mpls_tc and mpls_ttl) in kernel datapath and most control path i.e. setting
> mpls match and mpls actions working correctly. I have verified via tcpdump
> that proper mpls shim header is pushed/popped in all the cases.
>
> I have run into issues with handling of ovs action attributes for mpls
> actions with no argument. These are dec_mpls_ttl, copy_ttl_in and
> copy_ttl_out actions. The closest I could use for reference is
> OVS_ACTION_ATTR_POP_VLAN which uses following condition
>
> if (base->vlan_tci & htons(VLAN_CFI)) {
>     nl_msg_put_flag(odp_actions, OVS_ACTION_ATTR_POP_VLAN);
> }
> …

Maybe I'm not understanding your question but this condition isn't
related to the fact that the pop vlan doesn't take any arguments.
It's due to the fact that we first make any changes to a userspace
copy of the flow and then convert those to kernel actions at the end,
which has the effect of removing any redundant actions so if you have
set(X) then set(Y) we would just generate one kernel action to set Y
because we only compare against the base.  In the case of a decrement
action you would want the action to occur for every time that it
occurred in the original so there's no need for this type of
conditional.

That being said, I think the real reason for the issue that your
running into is that we don't normally have a direct correspondence
between OpenFlow and kernel actions, particularly for these types of
TTL actions.  If you look at the IP TTL decrement, there's no
corresponding kernel TTL decrement, only a set.  So each time that
userspace encounters a TTL decrement it decrements its copy by 1 (it
knows the original value because it was part of the original lookup)
and then generates a set at the end.  I think you could do something
similar to implement the three remaining MPLS TTL actions using your
original set MPLS TTL.