Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as flow rule criteria

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 10/11/18 1:49 PM, Dekel Peled wrote:
> As described in [1], a new rte_flow item is added to support metadata
> to use as flow rule match pattern.
> The metadata is an opaque item, fully controlled by the application.
>
> The use of metadata is relevant for egress rules only.
> It can be set in the flow rule using the RTE_FLOW_ITEM_META.
>
> An additional item 'tx_metadata' is added in union with existing member
> 'hash' of struct 'rte_mbuf'.
> It is used to carry the metadata item.
> Currently this union is used only for ingress packets, so using it for
> egress metadata will not cause conflicts.
>
> Application should set the packet metadata in the mbuf dedicated field,
> and set the PKT_TX_METADATA flag in the mbuf->ol_flags.
> The NIC will use the packet metadata as match criteria for relevant
> flow rules.
>
> This patch introduces metadata item type for rte_flow RTE_FLOW_ITEM_META,
> along with corresponding struct rte_flow_item_meta and ol_flag
> PKT_TX_METADATA.
>
> [1] "[RFC,v2] ethdev: support metadata as flow rule criteria"
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>

[...]

> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index b600b2d..8643722 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1191,6 +1191,27 @@ Normally preceded by any of:
>   - `Item: ICMP6_ND_NS`_
>   - `Item: ICMP6_ND_OPT`_
>   
> +Item: ``META``
> +^^^^^^^^^^^^^^
> +
> +Matches an application specific 32 bit metadata item.
> +
> +- Default ``mask`` matches any 32 bit value.
> +
> +.. _table_rte_flow_item_meta:
> +
> +.. table:: META
> +
> +   +----------+----------+---------------------------+
> +   | Field    | Subfield | Value                     |
> +   +==========+==========+===========================+
> +   | ``spec`` | ``data`` | 32 bit metadata value     |
> +   +----------+--------------------------------------+
> +   | ``last`` | ``data`` | upper range value         |
> +   +----------+----------+---------------------------+
> +   | ``mask`` | ``data`` | zeroed to match any value |
> +   +----------+----------+---------------------------+
> +

Is there a difference between any metadata value and
no metadata value at all?

> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 012577b..933f0e0 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -942,6 +942,11 @@ struct rte_eth_conf {
>    * for tunnel TSO.
>    */
>   #define DEV_TX_OFFLOAD_IP_TNL_TSO       0x00080000
> +/**
> + * Device supports match on metadata Tx offload..
> + * Application must set PKT_TX_METADATA and mbuf metadata field.
> + */
> +#define DEV_TX_OFFLOAD_MATCH_METADATA   0x00100000
>   
>   #define RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP 0x00000001
>   /**< Device supports Rx queue setup after device started*/

> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index a50b05c..1fa38db 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -182,6 +182,11 @@
>   /* add new TX flags here */
>   
>   /**
> + * Indicate that the metadata field in the mbuf is in use.
> + */
> +#define PKT_TX_METADATA	(1ULL << 41)
> +
> +/**
>    * UDP Fragmentation Offload flag. This flag is used for enabling UDP
>    * fragmentation in SW or in HW. When use UFO, mbuf->tso_segsz is used
>    * to store the MSS of UDP fragments.
> @@ -342,8 +347,9 @@
>   		PKT_TX_QINQ_PKT |        \
>   		PKT_TX_VLAN_PKT |        \
>   		PKT_TX_TUNNEL_MASK |	 \
> -		PKT_TX_MACSEC |		 \
> -		PKT_TX_SEC_OFFLOAD)
> +		PKT_TX_MACSEC |          \
> +		PKT_TX_SEC_OFFLOAD |	 \
> +		PKT_TX_METADATA)
>   
>   /**
>    * Mbuf having an external buffer attached. shinfo in mbuf must be filled.
> @@ -511,28 +517,41 @@ struct rte_mbuf {
>   	/** VLAN TCI (CPU order), valid if PKT_RX_VLAN is set. */
>   	uint16_t vlan_tci;
>   
> +	RTE_STD_C11
>   	union {
> -		uint32_t rss;     /**< RSS hash result if RSS enabled */
> -		struct {
> -			RTE_STD_C11
> -			union {
> -				struct {
> -					uint16_t hash;
> -					uint16_t id;
> +		union {
> +			uint32_t rss;     /**< RSS hash result if RSS enabled */
> +			struct {
> +				union {
> +					struct {
> +						uint16_t hash;
> +						uint16_t id;
> +					};
> +					uint32_t lo;
> +					/**< Second 4 flexible bytes */
>   				};
> +				uint32_t hi;
> +				/**< First 4 flexible bytes or FD ID, dependent
> +				 * on PKT_RX_FDIR_* flag in ol_flags.
> +				 */
> +			} fdir;	/**< Filter identifier if FDIR enabled */
> +			struct {
>   				uint32_t lo;
> -				/**< Second 4 flexible bytes */
> -			};
> -			uint32_t hi;
> -			/**< First 4 flexible bytes or FD ID, dependent on
> -			     PKT_RX_FDIR_* flag in ol_flags. */
> -		} fdir;           /**< Filter identifier if FDIR enabled */
> +				uint32_t hi;
> +			} sched;          /**< Hierarchical scheduler */
> +			/**< User defined tags. See rte_distributor_process() */
> +			uint32_t usr;
> +		} hash;                   /**< hash information */
>   		struct {
> -			uint32_t lo;
> +			/**
> +			 * Application specific metadata value
> +			 * for egress flow rule match.
> +			 * Valid if PKT_TX_METADATA is set.
> +			 */

Do I understand correctly that it is in CPU byte order?

> +			uint32_t tx_metadata;
>   			uint32_t hi;

I don't know if we need 'hi' here. Right now only one thing is
important - make it clear that it is not used. May be name it 'reserved'
instead of 'hi'.

It is interesting that hash::sched::hi is used for TxQ identification
in rte_event_eth_tx. The patch uses low bytes. So, seem to be fine.
However, if the separate structure is added in union for Tx fields,
it looks strange taking  rte_event_eth_tx into account.
So, I think it would be good document (comments) the purpose
of separate but unnamed structure in the union.

Andrew.