DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jack Min <jackmin@nvidia.com>
To: Ori Kam <orika@nvidia.com>,
	"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [RFC 1/2] ethdev: port flags for pre-configuration flow hints
Date: Thu, 7 Apr 2022 21:01:16 +0800	[thread overview]
Message-ID: <ebc6ed23-6ddc-c4d3-7621-bf9abc65027e@nvidia.com> (raw)
In-Reply-To: <MW2PR12MB4666625E257C548CF1067C05D6E69@MW2PR12MB4666.namprd12.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3572 bytes --]

  reply	other threads:[~2022-04-07 13:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07  5:30 [RFC 0/2] queue-based flow aged report Xiaoyu Min
2022-04-07  5:30 ` [RFC 1/2] ethdev: port flags for pre-configuration flow hints Xiaoyu Min
2022-04-07 11:27   ` Ori Kam
2022-04-07 13:01     ` Jack Min [this message]
2022-04-07 15:04   ` Stephen Hemminger
2022-04-08  2:35     ` Jack Min
2022-05-30 16:46   ` Thomas Monjalon
2022-05-31 10:47     ` Jack Min
2022-04-07  5:30 ` [RFC 2/2] ethdev: queue-based flow aged report Xiaoyu Min
2022-05-30 16:42   ` Thomas Monjalon
2022-05-31 11:06     ` Jack Min
2022-05-31 12:57       ` Thomas Monjalon
2022-06-01  7:39 ` [RFC 0/2] " Xiaoyu Min
2022-06-01  7:39   ` [RFC v2 1/2] ethdev: port flags for pre-configuration flow hints Xiaoyu Min
2022-06-01  9:03     ` Ori Kam
2022-06-01 18:20     ` Andrew Rybchenko
2022-06-02  5:50       ` Ori Kam
2022-06-02  9:38       ` Jack Min
2022-06-01  7:39   ` [RFC v2 2/2] ethdev: queue-based flow aged report Xiaoyu Min
2022-06-01 18:21     ` Andrew Rybchenko
2022-06-02  6:10       ` Ori Kam
2022-06-02 10:23         ` Jack Min
2022-06-06  9:47           ` Ori Kam
2022-06-02  9:39       ` Jack Min

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ebc6ed23-6ddc-c4d3-7621-bf9abc65027e@nvidia.com \
    --to=jackmin@nvidia.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).