[dpdk-dev] [RFC 1/3] ethdev: add item/action for SFT

Ori Kam orika at nvidia.com
Wed Sep 16 17:46:53 CEST 2020


Hi Andrey,

PSB

> -----Original Message-----
> From: Andrey Vesnovaty <andreyv at nvidia.com>
> Sent: Wednesday, September 9, 2020 11:30 PM
> 
> Attach SFT flow context to packet with SFT action.
> Match on SFT flow context (attached to packet),
> with SFT item.
> 
> Signed-off-by: Andrey Vesnovaty <andreyv at nvidia.com>
> ---
>  lib/librte_ethdev/rte_flow.h | 84 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 84 insertions(+)
> 
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index da8bfa5489..24390e6ab4 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -537,6 +537,12 @@ enum rte_flow_item_type {
>  	 */
>  	RTE_FLOW_ITEM_TYPE_ECPRI,
> 
> +	/**
You are missing the Meta, tag not relevant for RFC but please notice for the patch.

> +	 * Matches SFT context (see fields of struct rte_flow_item_sft).
> +	 *
> +	 * See struct rte_flow_item_sft.
> +	 */
> +	RTE_FLOW_ITEM_TYPE_SFT,
>  };
> 
>  /**
> @@ -1579,6 +1585,54 @@ static const struct rte_flow_item_ecpri
> rte_flow_item_ecpri_mask = {
>  };
>  #endif
> 
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ITEM_TYPE_SFT
> + *
> + * Matches context of flow in SFT table.
> + *
> + * 5-tuple: src/dest IP + src/dest port + IP protocol.
> + * zone: application defined value cupled with 5-tuple to identify flow,
> + * example - VxLAN, VLAN.
> + * SFT: Statfull flow table
> + * SFT in scope of ethernet device (port) is HW offloaded lookup table
> + * where key is zone + 5-tuple & value is statefull flow context.
> + * Contents of the SFT maintained by SFT PMD (see SFT PMD API in rte_sft).
> + *
> + * The structure describes SFT flow context.
> + * All the fields of the structure, except @p fid, should be considered as
> + * user defined.
> + * The @p fid assigned by RTE SFT & used as unique flow identifier.
> + * SFT context attached to packet by action ``SFT`` (see
> RTE_FLOW_ACTION_SFT).
> + *
> + * SFT default context defined as context attached to packet when there is no
> + * entry for the flow in SFT. The @p state has application reserved value
> + * meaning that SFT context for the packet undefined since entry wasn't found
> + * in SFT. If state 'undefined' then @p zone should be valid othervice @p fid
> + * should be valid.
> + *
> + * Context considered virtual since the method of storing this info on packet
> + * is PMD/implementation specific & may involve mapping methods if there is
> + * 'not enough bits' to store entire contents of struct rte_flow_item_sft.
> + *
> + * Maximal value/size of each field depends on HW capabilities and
> considered
> + * as implementation specific.
> + */
> +struct rte_flow_item_sft {
> +	union {
> +		uint32_t fid; /**< SFT flow identifier. */
> +		uint32_t zone; /**< Zone assigned to flow. */
> +	};
> +	uint8_t state; /**< User defined flow state. */
> +	uint8_t fid_valid:1; /**< fid field validity bit. */
> +	uint8_t zone_valid:1; /**< zone fieald validity bit. */
> +	uint8_t state_valid:1; /**< state fieald validity bit. */
> +	uint8_t user_data_size; /**< user_data buffer size. */
> +	uint8_t *user_data; /**< Arbitrary user data. */
> +};
> +
This object is only used to match and not set so
why do we need the union? I understand that later when reporting to the SFT in the application layer
sometimes you will get zone while other time you will get fid.
>From rte flow you are matching on given object which is 32 bit.
What are the matchable  fields? (fid / zone / user_data / fid_valid ... )
Do you think that some of the times the match will be on he fid other on the zone?
If so they should not be union.
I think zone is the responsibility of the application to save and to match. So I don't see why it is
needed here.

>  /**
>   * Matching pattern item definition.
>   *
> @@ -2132,6 +2186,15 @@ enum rte_flow_action_type {
>  	 * see enum RTE_ETH_EVENT_FLOW_AGED
>  	 */
>  	RTE_FLOW_ACTION_TYPE_AGE,
> +
> +	/**
> +	 * RTE_FLOW_ACTION_TYPE_SFT
> +	 *
> +	 * Set SFT context and redirect to continue processing.
> +	 *
> +	 * See struct rte_flow_action_sft.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_SFT,
>  };
> 
>  /**
> @@ -2721,6 +2784,27 @@ rte_flow_dynf_metadata_set(struct rte_mbuf *m,
> uint32_t v)
>  	*RTE_FLOW_DYNF_METADATA(m) = v;
>  }
> 
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ACTION_TYPE_SFT
> + *
> + * Attaches an SFT context (see struct rte_flow_item_sft) to packet.
> + *
> + * Performs lookup by *zone* and 5-tuple in SFT; if entry found the related SFT
> + * context will be attached othervise default SFT context attached (see
> + * 'SFT default context' in struct rte_flow_item_sft description).
> + * Adding action of type ``SFT`` to the list of rule actions may impose
> + * limitations on other rule actions added to the list, depending on specific
> + * PMD implementation.
> + *
> + * For 5-tuple, zone & SFT definitions see `struct rte_flow_item_sft`.
> + */
> +struct rte_flow_action_sft {
> +	uint32_t zone; /**< Zone for lookup in SFT */
> +};
> +
>  /*
>   * Definition of a single action.
>   *
> --
> 2.26.2

Thanks,
Ori



More information about the dev mailing list