[v3,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.
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
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?
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
> 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&data=02%7C01%7Cyskoh%40mellanox.com%7Cefd5b454b5ac4c84947108d62ac82a8c%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636743436575292609&sdata=2WbhDkF89hUV16zER4sfhvD5qDjw6geFQqE0kJQgdyM%3D&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&data=02%7C01%7Cyskoh%40mellanox.com%7Cefd5b454b5ac4c84947108d62ac82a8c%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636743436575292609&sdata=QbrBkMWIWVMlKb8839FG3U72VfLhRo%2BjGSHkTXT8ocQ%3D&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
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
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
>
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
>>
@@ -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
@@ -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*/
@@ -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.
@@ -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;