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.

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 
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 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)
2. (in next group) matching on the TTL , ACTION_DROP 

> 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. 

+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]
> April%2F096857.html&
> 747ae47841bc55e508d5a371d2f4%7Ca652971c7d2e4d9ba6a4d149256f461b%7
> C0%7C0%7C636594631626247567&sdata=3oTbKT6QwS1WiAIrkF885dEU76ep4
> xreuHoHiwDA2Ec%3D&reserved=0
> [2]
> resources%2Fonf-specifications%2Fopenflow%2Fopenflow-spec-
> v1.3.0.pdf&
> 1bc55e508d5a371d2f4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%
> 7C636594631626247567&sdata=e6uelVwIu1poE2uIvEJELuIzela8H%2B8HclQE5
> EdKEaM%3D&reserved=0
> --
> Adrien Mazarguil

Reply via email to