On 10/5/2018 2:39 PM, Andrew Rybchenko wrote:

On 10/5/18 4:31 PM, Ferruh Yigit wrote:

quoted

On 9/27/2018 2:57 PM, Dekel Peled wrote:

quoted

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.

In order to avoid change in mbuf API, exisitng field buf.hash.fdir.hi
is used to carry the metadata item. This field is used only in
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"
     http://mails.dpdk.org/archives/dev/2018-August/110194.html

Signed-off-by: Dekel Peled <redacted>

<...>

quoted

@@ -526,6 +532,12 @@ struct rte_mbuf {
  			uint32_t hi;
  			/**< First 4 flexible bytes or FD ID, dependent on
  			     PKT_RX_FDIR_* flag in ol_flags. */
+			/**
+			 * Above member has optional use on egress:
+			 * Application specific metadata value
+			 * for flow rule match.
+			 * Valid if PKT_TX_METADATA is set.
+			 */
  		} fdir;           /**< Filter identifier if FDIR enabled */

Any objection/comment to use hash.fdir.hi for this new "metadata" meaning? Olivier?

As for me, I'd prefer to see dedicated union member something like
it was suggested in [1].

Another comment, it was from Cristian while discussing something else, since
this field is for egress, shouldn't it be somewhere in second cache line
allocated for Tx?

Andrew.

[1] http://mails.dpdk.org/archives/dev/2018-September/111954.html