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

Andrew Rybchenko arybchenko at solarflare.com
Sun Oct 14 09:35:30 CEST 2018


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://mails.dpdk.org/archives/dev/2018-October/115267.html



More information about the dev mailing list