[v3,1/3] ethdev: support metadata as flow rule criteria
diff mbox series

Message ID 1538056677-33846-2-git-send-email-dekelp@mellanox.com
State Superseded, archived
Delegated to: Ferruh Yigit
Headers show
Series
  • *** SUBJECT HERE ***
Related show

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Dekel Peled Sept. 27, 2018, 1:57 p.m. UTC
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 <dekelp@mellanox.com>
---
 doc/guides/prog_guide/rte_flow.rst | 21 +++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev.c     |  1 +
 lib/librte_ethdev/rte_ethdev.h     |  5 +++++
 lib/librte_ethdev/rte_flow.c       |  1 +
 lib/librte_ethdev/rte_flow.h       | 24 ++++++++++++++++++++++++
 lib/librte_mbuf/rte_mbuf.c         |  2 ++
 lib/librte_mbuf/rte_mbuf.h         | 16 ++++++++++++++--
 7 files changed, 68 insertions(+), 2 deletions(-)

Comments

Ferruh Yigit Oct. 5, 2018, 1:31 p.m. UTC | #1
On 9/27/2018 2:57 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.
> 
> 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 <dekelp@mellanox.com>

<...>

> @@ -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?
Andrew Rybchenko Oct. 5, 2018, 1:39 p.m. UTC | #2
On 10/5/18 4:31 PM, Ferruh Yigit wrote:
> On 9/27/2018 2:57 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.
>>
>> 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 <dekelp@mellanox.com>
> <...>
>
>> @@ -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].

Andrew.

[1] http://mails.dpdk.org/archives/dev/2018-September/111954.html
Yongseok Koh Oct. 5, 2018, 6:20 p.m. UTC | #3
> On Oct 5, 2018, at 6:39 AM, Andrew Rybchenko <arybchenko@solarflare.com> wrote:
> 
> On 10/5/18 4:31 PM, Ferruh Yigit wrote:
>> On 9/27/2018 2:57 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.
>>> 
>>> 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"
>>>     https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-August%2F110194.html&amp;data=02%7C01%7Cyskoh%40mellanox.com%7Cefd5b454b5ac4c84947108d62ac82a8c%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636743436575292609&amp;sdata=2WbhDkF89hUV16zER4sfhvD5qDjw6geFQqE0kJQgdyM%3D&amp;reserved=0
>>> 
>>> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>> <...>
>> 
>>> @@ -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].
> 
> Andrew.
> 
> [1] https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-September%2F111954.html&amp;data=02%7C01%7Cyskoh%40mellanox.com%7Cefd5b454b5ac4c84947108d62ac82a8c%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636743436575292609&amp;sdata=QbrBkMWIWVMlKb8839FG3U72VfLhRo%2BjGSHkTXT8ocQ%3D&amp;reserved=0

FYI, I also mentioned that when I reviewed mlx5 part of this patchset and Dekel acked.
He'll make the change and submit a new version once he's back to the office.

Thanks,
Yongseok
Dekel Peled Oct. 8, 2018, 3:10 p.m. UTC | #4
Thanks, PSB

From: Andrew Rybchenko <arybchenko@solarflare.com> 
Sent: Friday, October 5, 2018 4:40 PM
To: Ferruh Yigit <ferruh.yigit@intel.com>; Dekel Peled <dekelp@mellanox.com>; wenzhuo.lu@intel.com; jingjing.wu@intel.com; bernard.iremonger@intel.com; dev@dpdk.org; olivier.matz@6wind.com; Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon <thomas@monjalon.net>
Cc: Shahaf Shuler <shahafs@mellanox.com>; Ori Kam <orika@mellanox.com>
Subject: Re: [PATCH v3 1/3] ethdev: support metadata as flow rule criteria

On 10/5/18 4:31 PM, Ferruh Yigit wrote:
On 9/27/2018 2:57 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.

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"
    https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-August%2F110194.html&data=02%7C01%7Cdekelp%40mellanox.com%7Ccc5ab6f21cd847d4b45008d62ac82949%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636743436510709804&sdata=AtPp27zdfM8G%2BbvgiLW47qSWDJElDrP2l8%2FHpNP04G0%3D&reserved=0

Signed-off-by: Dekel Peled mailto:dekelp@mellanox.com

<...>

@@ -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].

Andrew.

[1] https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2018-September%2F111954.html&data=02%7C01%7Cdekelp%40mellanox.com%7Ccc5ab6f21cd847d4b45008d62ac82949%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636743436510709804&sdata=S1iSzBG4NFNSwF%2B12Vu1b2VfXuwcYLha2Vxlybu8tXQ%3D&reserved=0


I will change it as suggested.
Dekel
Ferruh Yigit Oct. 9, 2018, 2:46 p.m. UTC | #5
On 10/5/2018 2:39 PM, Andrew Rybchenko wrote:
> On 10/5/18 4:31 PM, Ferruh Yigit wrote:
>> On 9/27/2018 2:57 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.
>>>
>>> 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 <dekelp@mellanox.com>
>> <...>
>>
>>> @@ -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
>
Andrew Rybchenko Oct. 9, 2018, 2:52 p.m. UTC | #6
On 10/9/18 5:46 PM, Ferruh Yigit wrote:
> On 10/5/2018 2:39 PM, Andrew Rybchenko wrote:
>> On 10/5/18 4:31 PM, Ferruh Yigit wrote:
>>> On 9/27/2018 2:57 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.
>>>>
>>>> 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 <dekelp@mellanox.com>
>>> <...>
>>>
>>>> @@ -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?

Tx writes to the first cache-line as well, so I see no problem in using hash
union for Tx. I think it is better to keep remaining space on the second
cache-line for the future use.

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

Patch
diff mbox series

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 |
+   +----------+----------+---------------------------+
+
 Actions
 ~~~~~~~
 
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index aa7730c..aa77439 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -157,6 +157,7 @@  struct rte_eth_xstats_name_off {
 	RTE_TX_OFFLOAD_BIT2STR(SECURITY),
 	RTE_TX_OFFLOAD_BIT2STR(UDP_TNL_TSO),
 	RTE_TX_OFFLOAD_BIT2STR(IP_TNL_TSO),
+	RTE_TX_OFFLOAD_BIT2STR(MATCH_METADATA),
 };
 
 #undef RTE_TX_OFFLOAD_BIT2STR
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 44b4fb3..a6ca82f 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -948,6 +948,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_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
index cff4b52..54e5ef8 100644
--- a/lib/librte_ethdev/rte_flow.c
+++ b/lib/librte_ethdev/rte_flow.c
@@ -66,6 +66,7 @@  struct rte_flow_desc_data {
 		     sizeof(struct rte_flow_item_icmp6_nd_opt_sla_eth)),
 	MK_FLOW_ITEM(ICMP6_ND_OPT_TLA_ETH,
 		     sizeof(struct rte_flow_item_icmp6_nd_opt_tla_eth)),
+	MK_FLOW_ITEM(META, sizeof(struct rte_flow_item_meta)),
 };
 
 /** Generate flow_action[] entry. */
diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index 0656e5e..83aa9f4 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -413,6 +413,14 @@  enum rte_flow_item_type {
 	 * See struct rte_flow_item_mark.
 	 */
 	RTE_FLOW_ITEM_TYPE_MARK,
+
+	/**
+	 * [META]
+	 *
+	 * Matches a metadata value specified in mbuf metadata field.
+	 * See struct rte_flow_item_meta.
+	 */
+	RTE_FLOW_ITEM_TYPE_META,
 };
 
 /**
@@ -1156,6 +1164,22 @@  struct rte_flow_item_icmp6_nd_opt_tla_eth {
 #endif
 
 /**
+ * RTE_FLOW_ITEM_TYPE_META.
+ *
+ * Matches a specified metadata value.
+ */
+struct rte_flow_item_meta {
+	uint32_t data;
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_META. */
+#ifndef __cplusplus
+static const struct rte_flow_item_meta rte_flow_item_meta_mask = {
+	.data = RTE_BE32(UINT32_MAX),
+};
+#endif
+
+/**
  * @warning
  * @b EXPERIMENTAL: this structure may change without prior notice
  *
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index e714c5a..4b25ae8 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -395,6 +395,7 @@  const char *rte_get_tx_ol_flag_name(uint64_t mask)
 	case PKT_TX_TUNNEL_UDP: return "PKT_TX_TUNNEL_UDP";
 	case PKT_TX_MACSEC: return "PKT_TX_MACSEC";
 	case PKT_TX_SEC_OFFLOAD: return "PKT_TX_SEC_OFFLOAD";
+	case PKT_TX_METADATA: return "PKT_TX_METADATA";
 	default: return NULL;
 	}
 }
@@ -435,6 +436,7 @@  const char *rte_get_tx_ol_flag_name(uint64_t mask)
 		  "PKT_TX_TUNNEL_NONE" },
 		{ PKT_TX_MACSEC, PKT_TX_MACSEC, NULL },
 		{ PKT_TX_SEC_OFFLOAD, PKT_TX_SEC_OFFLOAD, NULL },
+		{ PKT_TX_METADATA, PKT_TX_METADATA, NULL },
 	};
 	const char *name;
 	unsigned int i;
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 9ce5d76..ea75ad0 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.
@@ -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 */
 		struct {
 			uint32_t lo;