Re: [dpdk-dev] [PATCH v3 3/4] ethdev: add TTL change actions in flow API

[Adrien Mazarguil <adrien.mazarguil@6wind.com>]

On Mon, Apr 16, 2018 at 08:56:37AM +0000, Shahaf Shuler wrote:
> Monday, April 16, 2018 11:12 AM, Adrien Mazarguil:
> > Subject: Re: [dpdk-dev] [PATCH v3 3/4] ethdev: add TTL change actions in
> > flow API
> > 
> > Hi Shahaf,
> > 
> > On Mon, Apr 16, 2018 at 05:48:19AM +0000, Shahaf Shuler wrote:
> > > Hi Qi,
> > >
> > > Am wondering if we can make the below more generic and not tailored for
> > specific use cases.
> > 
> > Regarding this, please see my previous answer [1] where I asked Qi to make
> > his changes more focused on the use case at hand when it became clear all
> > this work was targeting OpenFlow.
> 
> OK,
> I missed that. Sorry for jumping in late.
> 
> > 
> > The OF specification [2] defines the behavior associated with each action, for
> > instance when a TTL is 0 or decrementing it would yield 0, the packet must be
> > dropped. Translating this to a generic decrement action for any packet field is
> > not so easy and not convenient.
> 
> I am not sure I understand why. It is to set -1 in the TTL field of the generic action. 
> We can define the corner cases more carefully as part of the actions. For example - no wrap around. 
> I did not understood the drop if TTL is 0 is part of the action (it is not described the action description[1]).
> Is this the case? 

I still need to comment the original patch :)

Basically I would like to make all these actions point to the OpenFlow
action documentation describing them with a disclaimer such as "These are
OpenFlow actions, here's a summary of what they do, see linked OF
documentation for details".

> I think it is wrong approach to introduce a "combo" actions (both decrements and drops if value) in rte_flow. 
> I would model such  operation by a set of (pseudo code)
> 1. ACTION_FIELD_DEC_INC , ACTION_GO_TO_GROUP
> 2. (in next group) matching on the TTL , ACTION_DROP 

If a device really implements something that does "check TTL on protocol $FOO,
decrement it, re-check TTL, update checksum, drop packet if any of the
previous steps failed", then by all means I think a dedicated action is
justified. It's also easier to document as "does what OpenFlow specifies"
and much more convenient to applications.

Another set of actions can be added for devices (or PMDs) with partial
support (e.g. to expose a "dumb" decrement capability as in the original
series).

The real question is are there devices that fully implement OF actions as
described by the linked spec? Can any missing bits be handled by PMDs
without a noticeable performance impact?

> > Therefore my opinion is that if OF actions as defined by this specification are
> > supported as hardware capabilities, it makes sense to define dedicated
> > rte_flow actions for each of them (although "OF" should be part of their
> > name for clarity).
> 
> I still think we may need in the future to support copy/increment/decrement of fields not specifically related to OF. 
> It is better to have APIs which will not change or have double meaning. 

We could add them later on a needed basis. Correct me if I'm wrong, but
right now OF is the only use case everyone has in mind. Application
developers will always favor a set of explicit OF actions over more
convoluted means of achieving the expected behavior.

> [1]
> +Action: ``IP_TTL_DEC``
> +^^^^^^^^^^^^^^^^^^^^^^
> +
> +Decrement IPv4 TTL or IPv6 hop limit field and update the IP checksum, 
> +only applies to packets that contain specific MPLS headers.
> +
> +.. _table_rte_flow_action_ip_ttl_dec:
> +
> +.. table:: IP_TTL_DEC
> 
> 
> > 
> > I'll comment the patch proper in a separate message.
> > 
> > [1]
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> > k.org%2Fml%2Farchives%2Fdev%2F2018-
> > April%2F096857.html&data=02%7C01%7Cshahafs%40mellanox.com%7C6d2b
> > 747ae47841bc55e508d5a371d2f4%7Ca652971c7d2e4d9ba6a4d149256f461b%7
> > C0%7C0%7C636594631626247567&sdata=3oTbKT6QwS1WiAIrkF885dEU76ep4
> > xreuHoHiwDA2Ec%3D&reserved=0
> > [2]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> > ww.opennetworking.org%2Fimages%2Fstories%2Fdownloads%2Fsdn-
> > resources%2Fonf-specifications%2Fopenflow%2Fopenflow-spec-
> > v1.3.0.pdf&data=02%7C01%7Cshahafs%40mellanox.com%7C6d2b747ae4784
> > 1bc55e508d5a371d2f4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%
> > 7C636594631626247567&sdata=e6uelVwIu1poE2uIvEJELuIzela8H%2B8HclQE5
> > EdKEaM%3D&reserved=0
> > 
> > --
> > Adrien Mazarguil
> > 6WIND

-- 
Adrien Mazarguil
6WIND