[RFC,1/2] ethdev: port flags for pre-configuration flow hints
Checks
Commit Message
The data-path focused flow rule management can manage flow rules in more
optimized way then tranditional one by using hits provided by
application in initialization phase.
In addition to the current hints we have in port attr, more hints could
be proivded by application about it's behaviour.
One example is how the application do with the same flow:
A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be
isolated and access based on queue, without lock for example.
This patch add flag about above situation and could be extanded to cover
more situations.
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
---
lib/ethdev/rte_flow.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Comments
Hi Jack,
> -----Original Message-----
> From: Jack Min <jackmin@nvidia.com>
> Sent: Thursday, April 7, 2022 8:31 AM
> Subject: [RFC 1/2] ethdev: port flags for pre-configuration flow hints
>
> The data-path focused flow rule management can manage flow rules in more
> optimized way then tranditional one by using hits provided by
> application in initialization phase.
>
> In addition to the current hints we have in port attr, more hints could
> be proivded by application about it's behaviour.
>
> One example is how the application do with the same flow:
> A. create/destroy flow on same queue but query flow on different queue
> or queue-less way (i.e, counter query)
> B. All flow operations will be exactly on the same queue, by which PMD
> could be in more optimized way then A because resource could be
> isolated and access based on queue, without lock for example.
>
> This patch add flag about above situation and could be extanded to cover
> more situations.
>
> Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
> ---
> lib/ethdev/rte_flow.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index d8827dd184..578dd837f5 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -4875,6 +4875,17 @@ rte_flow_flex_item_release(uint16_t port_id,
> const struct rte_flow_item_flex_handle *handle,
> struct rte_flow_error *error);
>
> +/**
> + * The flags of rte flow port
> + */
> +enum rte_flow_port_flag {
> + /**
> + * All flow operations for one specified flow will _strictlly_ happen
> + * on the same queue (create/destroy/query/update).
> + */
> + RTE_FLOW_PORT_FLAG_STRICT_QUEUE = RTE_BIT32(0),
> +};
> +
> /**
> * @warning
> * @b EXPERIMENTAL: this API may change without prior notice.
> @@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
> * @see RTE_FLOW_ACTION_TYPE_METER
> */
> uint32_t nb_meters;
> + /**
> + * Port flags.
> + * @see enum rte_flow_port_flag
> + */
> + enum rte_flow_port_flag flags;
Why the use of enum and not flags?
I guess there will be more flags in future, and those flags will not be related to the strict queue.
> };
>
> /**
> --
> 2.35.1
On 4/7/22 19:27, Ori Kam wrote:
> Hi Jack,
Hey Ori,
>
>> -----Original Message-----
>> From: Jack Min<jackmin@nvidia.com>
>> Sent: Thursday, April 7, 2022 8:31 AM
>> Subject: [RFC 1/2] ethdev: port flags for pre-configuration flow hints
>>
>> The data-path focused flow rule management can manage flow rules in more
>> optimized way then tranditional one by using hits provided by
>> application in initialization phase.
>>
>> In addition to the current hints we have in port attr, more hints could
>> be proivded by application about it's behaviour.
>>
>> One example is how the application do with the same flow:
>> A. create/destroy flow on same queue but query flow on different queue
>> or queue-less way (i.e, counter query)
>> B. All flow operations will be exactly on the same queue, by which PMD
>> could be in more optimized way then A because resource could be
>> isolated and access based on queue, without lock for example.
>>
>> This patch add flag about above situation and could be extanded to cover
>> more situations.
>>
>> Signed-off-by: Xiaoyu Min<jackmin@nvidia.com>
>> ---
>> lib/ethdev/rte_flow.h | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
>> index d8827dd184..578dd837f5 100644
>> --- a/lib/ethdev/rte_flow.h
>> +++ b/lib/ethdev/rte_flow.h
>> @@ -4875,6 +4875,17 @@ rte_flow_flex_item_release(uint16_t port_id,
>> const struct rte_flow_item_flex_handle *handle,
>> struct rte_flow_error *error);
>>
>> +/**
>> + * The flags of rte flow port
>> + */
>> +enum rte_flow_port_flag {
>> + /**
>> + * All flow operations for one specified flow will _strictlly_ happen
>> + * on the same queue (create/destroy/query/update).
>> + */
>> + RTE_FLOW_PORT_FLAG_STRICT_QUEUE = RTE_BIT32(0),
>> +};
>> +
>> /**
>> * @warning
>> * @b EXPERIMENTAL: this API may change without prior notice.
>> @@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
>> * @see RTE_FLOW_ACTION_TYPE_METER
>> */
>> uint32_t nb_meters;
>> + /**
>> + * Port flags.
>> + * @see enum rte_flow_port_flag
>> + */
>> + enum rte_flow_port_flag flags;
> Why the use of enum and not flags?
> I guess there will be more flags in future, and those flags will not be related to the strict queue.
Yes, you are right. We will have more flags, and they will not relate to
strict queue.
I will change it to "flags".
Thank you.
>> };
>>
>> /**
>> --
>> 2.35.1
On Thu, 7 Apr 2022 13:30:46 +0800
Xiaoyu Min <jackmin@nvidia.com> wrote:
> * @b EXPERIMENTAL: this API may change without prior notice.
> @@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
> * @see RTE_FLOW_ACTION_TYPE_METER
> */
> uint32_t nb_meters;
> + /**
> + * Port flags.
> + * @see enum rte_flow_port_flag
> + */
> + enum rte_flow_port_flag flags;
This would have to wait until 22.11 because it is ABI breakage.
Also, how would this work with old users of API?
On 4/7/22 23:04, Stephen Hemminger wrote:
> On Thu, 7 Apr 2022 13:30:46 +0800
> Xiaoyu Min<jackmin@nvidia.com> wrote:
>
>> * @b EXPERIMENTAL: this API may change without prior notice.
>> @@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
>> * @see RTE_FLOW_ACTION_TYPE_METER
>> */
>> uint32_t nb_meters;
>> + /**
>> + * Port flags.
>> + * @see enum rte_flow_port_flag
>> + */
>> + enum rte_flow_port_flag flags;
> This would have to wait until 22.11 because it is ABI breakage.
> Also, how would this work with old users of API?
I'm not familiar with DPKD API/ABI policy,
But as my understanding this one is marked as _experimental_ and also
all related APIs
The experimental is not considered as part of ABI, and we can change
them anytime, no?
We were waiting for a v2 of this patch.
More comments below.
07/04/2022 07:30, Xiaoyu Min:
> The data-path focused flow rule management can manage flow rules in more
> optimized way then tranditional one by using hits provided by
hits -> hints
> application in initialization phase.
>
> In addition to the current hints we have in port attr, more hints could
> be proivded by application about it's behaviour.
it's -> its
> One example is how the application do with the same flow:
flow -> flow rule ?
> A. create/destroy flow on same queue but query flow on different queue
> or queue-less way (i.e, counter query)
> B. All flow operations will be exactly on the same queue, by which PMD
> could be in more optimized way then A because resource could be
> isolated and access based on queue, without lock for example.
>
> This patch add flag about above situation and could be extanded to cover
extended
> more situations.
>
> Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
> ---
> +/**
> + * The flags of rte flow port
> + */
> +enum rte_flow_port_flag {
Don't use enum for bit flags.
> + /**
> + * All flow operations for one specified flow will _strictlly_ happen
I guess you mean "for a given flow rule"
strictlly -> _strictly_
On 5/31/22 00:46, Thomas Monjalon wrote:
> We were waiting for a v2 of this patch.
Hey Thomas,
Thank you for the comments.
Yes, I'll send v2.
> More comments below.
I'll update the patch in v2 accordingly.
>
> 07/04/2022 07:30, Xiaoyu Min:
>> The data-path focused flow rule management can manage flow rules in more
>> optimized way then tranditional one by using hits provided by
> hits -> hints
>
>> application in initialization phase.
>>
>> In addition to the current hints we have in port attr, more hints could
>> be proivded by application about it's behaviour.
> it's -> its
>
>> One example is how the application do with the same flow:
> flow -> flow rule ?
>
>> A. create/destroy flow on same queue but query flow on different queue
>> or queue-less way (i.e, counter query)
>> B. All flow operations will be exactly on the same queue, by which PMD
>> could be in more optimized way then A because resource could be
>> isolated and access based on queue, without lock for example.
>>
>> This patch add flag about above situation and could be extanded to cover
> extended
>
>> more situations.
>>
>> Signed-off-by: Xiaoyu Min<jackmin@nvidia.com>
>> ---
>> +/**
>> + * The flags of rte flow port
>> + */
>> +enum rte_flow_port_flag {
> Don't use enum for bit flags.
>
>> + /**
>> + * All flow operations for one specified flow will _strictlly_ happen
> I guess you mean "for a given flow rule"
>
> strictlly -> _strictly_
>
>
>
@@ -4875,6 +4875,17 @@ rte_flow_flex_item_release(uint16_t port_id,
const struct rte_flow_item_flex_handle *handle,
struct rte_flow_error *error);
+/**
+ * The flags of rte flow port
+ */
+enum rte_flow_port_flag {
+ /**
+ * All flow operations for one specified flow will _strictlly_ happen
+ * on the same queue (create/destroy/query/update).
+ */
+ RTE_FLOW_PORT_FLAG_STRICT_QUEUE = RTE_BIT32(0),
+};
+
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice.
@@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
* @see RTE_FLOW_ACTION_TYPE_METER
*/
uint32_t nb_meters;
+ /**
+ * Port flags.
+ * @see enum rte_flow_port_flag
+ */
+ enum rte_flow_port_flag flags;
};
/**