[dpdk-dev] [PATCH v5 1/3] ethdev: add generic TTL rewrite actions

Jack Min jackmin at mellanox.com
Tue Oct 16 04:03:35 CEST 2018


On 18-10-14 10:35:30, Andrew Rybchenko wrote:
> On 13.10.2018 06:24, Jack Min wrote:
> > rewrite TTL by decrease or just set it directly
> > it's not necessary to check if the final result
> > is zero or not
> > 
> > This is slightly different from the one defined
> > by openflow and more generic
> > 
> > Signed-off-by: Xiaoyu Min <jackmin at mellanox.com>
> > Acked-by: Yongseok Koh <yskoh at mellanox.com>
> > ---
> 
> [...]
> 
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index 68bbf57d0..f102e6939 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1579,6 +1579,26 @@ enum rte_flow_action_type {
> >   	 * No associated configuration structure.
> >   	 */
> >   	RTE_FLOW_ACTION_TYPE_MAC_SWAP,
> > +
> > +	/**
> > +	 * Decrease TTL value directly
> > +	 *
> > +	 * If flow pattern doesn't define a valid RTE_FLOW_ITEM_TYPE_IPV4, or
> > +	 * RTE_FLOW_ITEM_TYPE_IPV6, the PMD should return a
> > +	 * RTE_FLOW_ERROR_TYPE_ACTION error.
> > +	 */
> > +	RTE_FLOW_ACTION_TYPE_DEC_TTL,
> > +
> > +	/**
> > +	 * Set TTL value
> > +	 *
> > +	 * If flow pattern doesn't define a valid RTE_FLOW_ITEM_TYPE_IPV4, or
> > +	 * RTE_FLOW_ITEM_TYPE_IPV6, the PMD should return a
> > +	 * RTE_FLOW_ERROR_TYPE_ACTION error.
> > +	 *
> > +	 * See struct rte_flow_action_set_ttl
> > +	 */
> > +	RTE_FLOW_ACTION_TYPE_SET_TTL,
> >   };
> >   /**
> 
> As I understand it is one more case where the following note from Adrien
> is applicable [1]:
> 
> <begin quote>
> 
> Another problem is that you must not require actions to rely on specific
> pattern content:
> 
>  [...]
>  *
>  * Decapsulate outer most tunnel from matched flow.
>  *
>  * The flow pattern must have a valid tunnel header
>  */
>  RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP,
> 
> For maximum flexibility, all actions should be usable on their own on empty
> pattern. On the other hand, you can document undefined behavior when
> performing some action on traffic that doesn't contain something.
> 
> Reason is that invalid traffic may have already been removed by other flow
> rules (or whatever happens) before such a rule is reached; it's a user's
> responsibility to provide such guarantee.
> 
> When parsing an action, a PMD is not supposed to look at the pattern. Action
> list should contain all the needed info, otherwise it means the API is badly
> defined.
> 
> I'm aware the above makes it tough to implement something like
> RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP as defined in this series, but that's
> unfortunately why I think it must not be defined like that.
> 
> <end quote>
> 
> [1] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-October%2F115267.html&data=02%7C01%7Cjackmin%40mellanox.com%7C8297d07c910e4aa6b4f508d631a7ab8e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636750993538615097&sdata=q0ywvMqqtRr%2BHp%2FBHLGtMF3x84kwPooZ7eYfdxmHtUs%3D&reserved=0
> 
Alright, I'will document this as PMD's limitation not API's.

-Jack


More information about the dev mailing list