[v4,1/3] ethdev: support metadata as flow rule criteria
Checks
Commit Message
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>
---
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 | 57 +++++++++++++++++++++++++-------------
7 files changed, 92 insertions(+), 19 deletions(-)
Comments
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.
Thanks, PSB.
From: Andrew Rybchenko <arybchenko@solarflare.com>
Sent: Tuesday, October 16, 2018 5:12 PM
To: Dekel Peled <dekelp@mellanox.com>; wenzhuo.lu@intel.com; jingjing.wu@intel.com; bernard.iremonger@intel.com; olivier.matz@6wind.com; Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com
Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam <orika@mellanox.com>; Nikhil Rao <nikhil.rao@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as flow rule criteria
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><mailto: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?
<DP> Value Zero is considered as no metadata value.
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?
<DP> Yes. The metadata value is not sent out to network.
+ 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'.
<DP> Accepted, I will rename it.
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.
<DP> Accepted, I will add comment.
Andrew.
On 10/17/18 8:27 AM, Dekel Peled wrote:
>
> Thanks, PSB.
>
> *From:* Andrew Rybchenko <arybchenko@solarflare.com>
> *Sent:* Tuesday, October 16, 2018 5:12 PM
> *To:* Dekel Peled <dekelp@mellanox.com>; wenzhuo.lu@intel.com;
> jingjing.wu@intel.com; bernard.iremonger@intel.com;
> olivier.matz@6wind.com; Adrien Mazarguil <adrien.mazarguil@6wind.com>;
> Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com
> *Cc:* Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam
> <orika@mellanox.com>; Nikhil Rao <nikhil.rao@intel.com>
> *Subject:* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as
> flow rule criteria
>
> 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> <mailto: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?
>
> <DP> Value Zero is considered as no metadata value.
>
Not sure that I understand.
Is flow rule with no META item equivalent to flow rule with
META item and mask.data==0?
Flow rule with no META item matches packets with and
without metadata.
Flow rule with META item and mask.data==0 could match
packets with metadata provided and any value, or could
be equivalent to no META item at all.
(I'm asking since no IPv4 item and empty IPv4 item are
different things).
From: Andrew Rybchenko <arybchenko@solarflare.com>
Sent: Wednesday, October 17, 2018 9:03 AM
To: Dekel Peled <dekelp@mellanox.com>; wenzhuo.lu@intel.com; jingjing.wu@intel.com; bernard.iremonger@intel.com; olivier.matz@6wind.com; Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com
Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam <orika@mellanox.com>; Nikhil Rao <nikhil.rao@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as flow rule criteria
On 10/17/18 8:27 AM, Dekel Peled wrote:
Thanks, PSB.
From: Andrew Rybchenko <arybchenko@solarflare.com><mailto:arybchenko@solarflare.com>
Sent: Tuesday, October 16, 2018 5:12 PM
To: Dekel Peled <dekelp@mellanox.com><mailto:dekelp@mellanox.com>; wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>; jingjing.wu@intel.com<mailto:jingjing.wu@intel.com>; bernard.iremonger@intel.com<mailto:bernard.iremonger@intel.com>; olivier.matz@6wind.com<mailto:olivier.matz@6wind.com>; Adrien Mazarguil <adrien.mazarguil@6wind.com><mailto:adrien.mazarguil@6wind.com>; Thomas Monjalon <thomas@monjalon.net><mailto:thomas@monjalon.net>; ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>
Cc: Shahaf Shuler <shahafs@mellanox.com><mailto:shahafs@mellanox.com>; dev@dpdk.org<mailto:dev@dpdk.org>; Ori Kam <orika@mellanox.com><mailto:orika@mellanox.com>; Nikhil Rao <nikhil.rao@intel.com><mailto:nikhil.rao@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as flow rule criteria
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><mailto: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?
<DP> Value Zero is considered as no metadata value.
Not sure that I understand.
Is flow rule with no META item equivalent to flow rule with
META item and mask.data==0?
Flow rule with no META item matches packets with and
without metadata.
Flow rule with META item and mask.data==0 could match
packets with metadata provided and any value, or could
be equivalent to no META item at all.
(I'm asking since no IPv4 item and empty IPv4 item are
different things).
<DP> mask is not relevant for this item.
I will rephrase the text:
Item: ``META``
^^^^^^^^^^^^^^
Matches an application specific 32 bit metadata item.
- Default ``mask`` matches the specified metadata value.
.. _table_rte_flow_item_meta:
.. table:: META
+----------+----------+--------------------------------------+
| Field | Subfield | Value | +==========+==========+=======================================+
| ``spec`` | ``data`` | 32 bit metadata value |
+----------+-------------------------------------------------+
| ``last`` | ``data`` | upper range value |
+----------+----------+--------------------------------------+
| ``mask`` | ``data`` | ignored, default mask matches "spec" |
+----------+----------+--------------------------------------+
@@ -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
~~~~~~~
@@ -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
@@ -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*/
@@ -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. */
@@ -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
*
@@ -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;
@@ -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.
+ */
+ uint32_t tx_metadata;
uint32_t hi;
- } sched; /**< Hierarchical scheduler */
- uint32_t usr; /**< User defined tags. See rte_distributor_process() */
- } hash; /**< hash information */
+ };
+ };
/** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
uint16_t vlan_tci_outer;