[RFC,v2,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 than traditional one by using hints provided by
application in initialization phase.
In addition to the current hints we have in port attr, more hints could
be provided by application about its behaviour.
One example is how the application do with the same 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 extended to cover
more situations.
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
---
lib/ethdev/rte_flow.h | 11 +++++++++++
1 file changed, 11 insertions(+)
Comments
Hi Jack,
> -----Original Message-----
> From: Jack Min <jackmin@nvidia.com>
> Sent: Wednesday, June 1, 2022 10:39 AM
> Subject: [RFC v2 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 than traditional one by using hints provided by
> application in initialization phase.
>
> In addition to the current hints we have in port attr, more hints could
> be provided by application about its behaviour.
>
> One example is how the application do with the same 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 extended to cover
> more situations.
>
> Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
> ---
> lib/ethdev/rte_flow.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index d8827dd184..38439fcd1d 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
> struct rte_flow_queue_info *queue_info,
> struct rte_flow_error *error);
>
> +/**
> + * Indicate all operations for a given flow rule will _strictly_ happen
> + * on the same queue (create/destroy/query/update).
> + */
> +#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
> +
> /**
> * @warning
> * @b EXPERIMENTAL: this API may change without prior notice.
> @@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
> * @see RTE_FLOW_ACTION_TYPE_METER
> */
> uint32_t nb_meters;
> + /**
> + * Port flags.
> + * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
> + */
> + uint32_t flags;
> };
>
> /**
> --
> 2.36.1
Acked-by: Ori Kam <orika@nvidia.com>
Best,
Ori
Summary must not be a statement. May be:
ethdev: add strict queue to pre-configuration flow hints
On 6/1/22 10:39, Xiaoyu Min wrote:
> The data-path focused flow rule management can manage flow rules in more
> optimized way than traditional one by using hints provided by
> application in initialization phase.
>
> In addition to the current hints we have in port attr, more hints could
> be provided by application about its behaviour.
>
> One example is how the application do with the same 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 extended to cover
> more situations.
>
> Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
> ---
> lib/ethdev/rte_flow.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index d8827dd184..38439fcd1d 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
> struct rte_flow_queue_info *queue_info,
> struct rte_flow_error *error);
>
> +/**
> + * Indicate all operations for a given flow rule will _strictly_ happen
> + * on the same queue (create/destroy/query/update).
> + */
> +#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
> +
> /**
> * @warning
> * @b EXPERIMENTAL: this API may change without prior notice.
> @@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
> * @see RTE_FLOW_ACTION_TYPE_METER
> */
> uint32_t nb_meters;
> + /**
> + * Port flags.
> + * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
I'm not sure that it is a good idea to list flags here.
If so, it will be required to add all future flags here.
So, may be just "Port flags (RTE_FLOW_PORT_FLAG_*)"
> + */
> + uint32_t flags;
> };
>
> /**
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Wednesday, June 1, 2022 9:21 PM
> Subject: Re: [RFC v2 1/2] ethdev: port flags for pre-configuration flow hints
>
> Summary must not be a statement. May be:
> ethdev: add strict queue to pre-configuration flow hints
>
> On 6/1/22 10:39, Xiaoyu Min wrote:
> > The data-path focused flow rule management can manage flow rules in more
> > optimized way than traditional one by using hints provided by
> > application in initialization phase.
> >
> > In addition to the current hints we have in port attr, more hints could
> > be provided by application about its behaviour.
> >
> > One example is how the application do with the same 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 extended to cover
> > more situations.
> >
> > Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
> > ---
> > lib/ethdev/rte_flow.h | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> > index d8827dd184..38439fcd1d 100644
> > --- a/lib/ethdev/rte_flow.h
> > +++ b/lib/ethdev/rte_flow.h
> > @@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
> > struct rte_flow_queue_info *queue_info,
> > struct rte_flow_error *error);
> >
> > +/**
> > + * Indicate all operations for a given flow rule will _strictly_ happen
> > + * on the same queue (create/destroy/query/update).
> > + */
> > +#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
> > +
> > /**
> > * @warning
> > * @b EXPERIMENTAL: this API may change without prior notice.
> > @@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
> > * @see RTE_FLOW_ACTION_TYPE_METER
> > */
> > uint32_t nb_meters;
> > + /**
> > + * Port flags.
> > + * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
>
> I'm not sure that it is a good idea to list flags here.
> If so, it will be required to add all future flags here.
> So, may be just "Port flags (RTE_FLOW_PORT_FLAG_*)"
>
+1
> > + */
> > + uint32_t flags;
> > };
> >
> > /**
On 6/2/22 02:20, Andrew Rybchenko wrote:
> Summary must not be a statement. May be:
> ethdev: add strict queue to pre-configuration flow hints
Ok, I'll change to this.
>
> On 6/1/22 10:39, Xiaoyu Min wrote:
>> The data-path focused flow rule management can manage flow rules in more
>> optimized way than traditional one by using hints provided by
>> application in initialization phase.
>>
>> In addition to the current hints we have in port attr, more hints could
>> be provided by application about its behaviour.
>>
>> One example is how the application do with the same 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 extended to cover
>> more situations.
>>
>> Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
>> ---
>> lib/ethdev/rte_flow.h | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
>> index d8827dd184..38439fcd1d 100644
>> --- a/lib/ethdev/rte_flow.h
>> +++ b/lib/ethdev/rte_flow.h
>> @@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
>> struct rte_flow_queue_info *queue_info,
>> struct rte_flow_error *error);
>> +/**
>> + * Indicate all operations for a given flow rule will _strictly_ happen
>> + * on the same queue (create/destroy/query/update).
>> + */
>> +#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
>> +
>> /**
>> * @warning
>> * @b EXPERIMENTAL: this API may change without prior notice.
>> @@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
>> * @see RTE_FLOW_ACTION_TYPE_METER
>> */
>> uint32_t nb_meters;
>> + /**
>> + * Port flags.
>> + * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
>
> I'm not sure that it is a good idea to list flags here.
> If so, it will be required to add all future flags here.
Yes, it will become a lot later on.
> So, may be just "Port flags (RTE_FLOW_PORT_FLAG_*)"
Sure.
>
>> + */
>> + uint32_t flags;
>> };
>> /**
>
@@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
struct rte_flow_queue_info *queue_info,
struct rte_flow_error *error);
+/**
+ * Indicate all operations for a given flow rule will _strictly_ happen
+ * on the same queue (create/destroy/query/update).
+ */
+#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
+
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice.
@@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
* @see RTE_FLOW_ACTION_TYPE_METER
*/
uint32_t nb_meters;
+ /**
+ * Port flags.
+ * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
+ */
+ uint32_t flags;
};
/**