From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A1075A0542; Tue, 31 May 2022 13:07:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 55002400EF; Tue, 31 May 2022 13:07:10 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2054.outbound.protection.outlook.com [40.107.220.54]) by mails.dpdk.org (Postfix) with ESMTP id 967C4400D6 for ; Tue, 31 May 2022 13:07:08 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eMv/VXLMPMzYwMgoqAsnRmcICTpRzQyHSLIlYx2QqcN/V73WfXUxM0bZ4L0FCSqbkDZ8pEzwAwUDt+i6SlotHpoF7Xa+1JEKnlUa7NoQdRMOD3VdOooFBf/x6nmP+9AJ/xIOvOthjg01EDOmBL49Y9ZjRjJYTeAMIiWz8lKM8YLV1QD9fX7BE96vp1VFThMZAe+PajHnbH9wuvEiKHz0doWZx1Dngg+btR5m/V0GMb23sixDbSnlzS03OAKFhTnVG/59kJhVtZ0bUvVn6kckMuZNMd5BWwTOX+hOfiE3fj5uLicxOvm6smlDfLh2CXZFVXDTmL5c3yrSFO96uzl17g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=J1D4RjvsDSWgsSuhjgz59ynFDXnbcLoazUTyk6STvL0=; b=Pg08y9pQICsiu7tvvMURvHXkaipXmn1lguJSJHXLytw2Q9qKSnuMtVu+2e/lMle32RggkqOT/ZVnq1i5zAJ7nU2Vpv7NTDAk/Msutz7YRIothOX/eJqMy/Uvbupv7lChT28dqU/owANQe/4TeOXOQb4RILCpHUB797nlCRME0eHlD217CI2VVFHwPwRYLrdKfXiv1mNaOgyIe1WYIwa2LJufhLDCkOayIqA8LKleraUnzE125gIbzJKjP2oLzrKznAsi4dA4oKo+B4vjx65Nr4nXBiL1AmWl7beYLIKbE7+Gzvlnuae5K3IgxAtlaqJ+VR78Qan2yMJ7XhRUWUYxiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J1D4RjvsDSWgsSuhjgz59ynFDXnbcLoazUTyk6STvL0=; b=uM8qSE2hgBo0D3gDmOm1CiVCXAbLfiCFX+Yl7JYmcZ4O0hhDsSFxjdsxV+p9ScvkzdGtR55G8dpUO9COPVNQB7WeJI3TriiY++Xz/rNi/WiaNRjRm05BU8DsnNx9+EIWYBGr/SuNRqzJsnic+ON/7zfEucYnR8tM0ZEfxHmvNh+BlOP1t2QcdqD3eNlL9b7K8FVOHBma5djDe/VBe/+BnSJ9ATNAgeF/v5/xJhdYD4xKY+beusLOSt8MgMKSnPPo/BSEzPZ8UBRS6gnq+z4UswF7XFxdSkz3MVU/fGEOZPhX70U5xfV+0prI/IILmOChxMkFjjTnr301tmXWRnrGgg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from CO6PR12MB5459.namprd12.prod.outlook.com (2603:10b6:303:13b::16) by BN8PR12MB3425.namprd12.prod.outlook.com (2603:10b6:408:61::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12; Tue, 31 May 2022 11:07:01 +0000 Received: from CO6PR12MB5459.namprd12.prod.outlook.com ([fe80::34ef:8717:3038:667]) by CO6PR12MB5459.namprd12.prod.outlook.com ([fe80::34ef:8717:3038:667%3]) with mapi id 15.20.5314.012; Tue, 31 May 2022 11:07:01 +0000 Content-Type: multipart/alternative; boundary="------------HiPBRcNNH1xVdAKwo421cHEJ" Message-ID: <9f20256d-002d-e5d5-d4aa-a4c84deab79f@nvidia.com> Date: Tue, 31 May 2022 19:06:54 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC 2/2] ethdev: queue-based flow aged report Content-Language: en-US To: Thomas Monjalon Cc: Ori Kam , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org References: <9b673505092754dca22df7939cc009930864b45c.1649308627.git.jackmin@nvidia.com> <2183304.iZASKD2KPV@thomas> From: Jack Min In-Reply-To: <2183304.iZASKD2KPV@thomas> X-ClientProxiedBy: HK2PR0401CA0020.apcprd04.prod.outlook.com (2603:1096:202:2::30) To CO6PR12MB5459.namprd12.prod.outlook.com (2603:10b6:303:13b::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c183fd18-ee72-4acc-0d77-08da42f5afb5 X-MS-TrafficTypeDiagnostic: BN8PR12MB3425:EE_ X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GPnz7Tqt4aMS7QBTp40KTWe/6ZlLKYgFy6rwb0s5EsXBDRco1y/HZD4ngVdhEW4iz3QOsEZHoumNTfIphnkhwBWkd9Mm5nlLZJgWTFhV3ZdEw4GvzZwDYu9/sW0my5Id/xeXj80ncv2emw2sLCO2szw8HeNAJVShEi5fSHVWVLWyYB1kdpwacKDmERFCymZxBgN9twrQsHIXfSpvS4BRyxdjgwGd3mpTmKQb6LHlgVfuxMoU6o1I+lFIBxVTc1FMOpj6R1xy/kkkmwmsUS/eD2CA0Rto7G1hf5Dot8MIsVZwMco/FEb1Zp85qazUMjNpxDs7qF8jOACrwFiHnX/Oz/G6q5dOl5wO2xTEthuByIlcaB2AWBWMGBzDgmD/X2zI3BHqR3LwasPXwkcGTpXHFJgp5ODqrWcyOf8MQO7SysYOOMFeMclOj85GNqBtvRdjvBdgPWW/NZyRa71m6fbSeLVQf8Jl0yOx0buTlbaLG9ND6GRWS0eCJq2+atByMkDBR4aqf59RINO7E8W0lMOStFHDK+AoXbffRlFOs5AQXeBMikFHQtr3sz67bufUHaF05VP71hv1hQ+ABmKrg8w8OP7Z9MDYKfq4zm2/X2D6+8fF7U3rLzo+vtsb0stZEalJUKlx1XnXn3MazPHSClxxKxh8y3LATdE7PIsan/Jk1igKpSgKItmMe+U+7RWR/zXdlf71qKSmx/vXk3BzAu1oVx9kMAUqnuBhgdc9bVpTmLOL7ldubhGUpMq2QdMlCLZU X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR12MB5459.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38100700002)(31696002)(186003)(4326008)(66946007)(66556008)(6916009)(66476007)(83380400001)(54906003)(8676002)(2906002)(316002)(31686004)(6486002)(26005)(6506007)(508600001)(6512007)(36756003)(8936002)(33964004)(5660300002)(6666004)(53546011)(86362001)(2616005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dEo4QWdyK0dDN1pwMlc1aUt1cEIxY2NWNUpEL1J1Z1N4ZWdTME11WmowQmpO?= =?utf-8?B?Qmd6aTJDMmM4Zmc1N3VLNjFEUjNXZkZyNllyYkdQOHptQjdFTFhGVHg4TlA5?= =?utf-8?B?dGpDWE5qWElINTBySVhscFVaQmd5ZEJ6eFNHemZkd3RxQnVwTVdFaWRkL21x?= =?utf-8?B?MVRmUTFjeGNWK0xLajRNN0swOEtNam5laUxSSCtyeHkvd0c0dFp0aEcwTDFR?= =?utf-8?B?S044NjhzWmNUbzFhY2lpRXZuM1Jwd0d1YWJjL0xyQkwvSWROZnEzdW1iQzlP?= =?utf-8?B?RWZ6aEpzZjdXTUdGWlZnVXFnYU5Na3dTT09Xcmt5WTg3OThwemRJU21rRFp3?= =?utf-8?B?RDUxUnVqY3p2NlI1SnRmcW52RzBycitsckNkV01qNEdlSEx3QjBNSlRCMlQz?= =?utf-8?B?SGpkb1JnVWNnS0VMZzBTRjhzTHV0VVZxalYxREw2TGV5c3RQVjZTVjZiMzV1?= =?utf-8?B?UG9jSFlFR1BRc2FlTUdSUjgxa0QrRTFza09ZZUpDUFFvbkpjNytucHNrUlo0?= =?utf-8?B?SGxBbVZWL2luN2Zib3FjY1JpV1psZyt6a0hMQVl1cUVsdkNKQU1FbTh1Ym5M?= =?utf-8?B?aXZNais2WFlKSy9pYW45UjdVT28wcE81Witjc1hNNmhEQnFNc1A0MWkwNk55?= =?utf-8?B?bEErRU9odXhEU0pCZHVoeUFZcG1WSU85Qms4Nk9DZ0dRVTg4KzJhV3hYazdw?= =?utf-8?B?aklMQ3RCNTg3RGQ5cXBDaXV0RjRSTUJZZDQ1SUNpWmVVQ0pHdFJNczAwM2d0?= =?utf-8?B?SVVnY1BrSGVaUHd3Yml4MDZyeUxSOVpBeXhaa0ZTTi9PaENZejdhbElMQmhu?= =?utf-8?B?VkQxSkh0aGlmNW11QVRYY0ZZa0FpaXhiOWJ1REdQNVh0aEVuMG04YzI2ZHRJ?= =?utf-8?B?VVNRMXE1ZHF3MWF5YkxxNXJqVkJDc3pFVzh4UHFtaGs5anVua3dhTEpLYUxJ?= =?utf-8?B?SFRwL2lvN3JieTlUbU1NVjV6WFpxVGV0cm5XWVY1c1dRY0dKdkptWUtXY2F6?= =?utf-8?B?R0ZUT0NGMzUxWnNZdDNpTzBncWN2M2dHZTNrU1UyeSttTlR1YnBJckxtNU45?= =?utf-8?B?OTRXczZ0dm80MVo5WlhVcWMwYXdUZzJqbjNLRFVBcTVScHppbWdtZUM5Szh3?= =?utf-8?B?M2JHdVZCeTh3b3dlcTNubEVmVTVVTzJqQm81Rllxd0tKV2t1Tno2SldqMitj?= =?utf-8?B?dFE0Qk9hVXJGNUU0eVNDUUs4VkM0eWU4L20rb3oza29IZ0d3bCtZVFM3RjFn?= =?utf-8?B?eExlc2o0dEZzR2hqb21ZODFMVkN3OUNlcGVvTnI3Tk1JT2JOV042K0wxQUQz?= =?utf-8?B?YUJqdFMxZWkrRTZyYzZIMTM3aGpnU1FFbnRHREVudXhIS2ZuYUxWVHJHdWJi?= =?utf-8?B?VW5FeXJrZUd4Y3ZvY05neC9iaHY2Z0U3VnBid0I3T2Z1VjFvKzYwQ0d5M1lY?= =?utf-8?B?VUpHOXN5MkppZFhaaDJDMnQyWmN0OU5Wb0tSdDd0ZXBmaUpVSTVvNWd2YVBY?= =?utf-8?B?Zk80Y0RHZDg2anVVcUQ5SEhBem95TUdwL3o1NTlxWmpITUhhOG01WHRvR3dk?= =?utf-8?B?ZDN1YVdlcTZuVlNLejAvSnMwNXg4aVRKeGFzdVc0d29ab2Rkbll3RHJibDl6?= =?utf-8?B?RTViWkltVTZHSi9UQ0pXN04xa1k2RFZnT1dRZVQ4Ukc5U2lDSXh2SWIrMHFa?= =?utf-8?B?UUlTNVlIalJwZmpjNGwzRVhXMkNFSHZHRVp3OHc0T3MxYVc0dHdidHBsV3lJ?= =?utf-8?B?RTJaQThXZSthS2lrOEJRWmpqdXBYenkzalhEYzlESmpDTUJiVFI4MjQ3WnJl?= =?utf-8?B?dTNFVEM0WWZhdzV0UzlxOWI5cWNpQWR0aC81MTdQaWkvRUhHZDk0YUxrMFRJ?= =?utf-8?B?OC9VUVBPSTVGbEJrMFIxNUw0NEd1ZEJCcVUrSE4yQUNMRTJkMVVQS04xZ3hP?= =?utf-8?B?NDNjczVjU0MyNUlGVVU4dm5NNWxrOE1sU1BRd0w5YUt1ZTNwVERhR3FFTEdL?= =?utf-8?B?SmN0S2VsdlptcmtxYUEzWXlVSzcweWtBaTVTT2ZCbWRlZXJBVmtyM1hHbWk0?= =?utf-8?B?MUVjV3NiVzN4NVpIVG9GaVl0UFQrRGdIK1ppSVVLL21US3VmalB4Vkl1Z2dY?= =?utf-8?B?ZG1oUEZFRkczdkZXRVhOSU5LSk1jODBqUnh5NTZzZEEyVk5CSE1ybjBSMFJz?= =?utf-8?B?Z1FlRmgrVnp6VHBzOElWeDRMSHM4MFpwRE5zQnlRQVpUaWtrOFFwck9paEJt?= =?utf-8?B?enQzU3grYm9Wd0NHeDlCRVhzeGVPVWcxUzMzdDI2QytLSVg5VThadG1paVBv?= =?utf-8?B?UFFJWG42SDJRYWRCR3VlSUk2ZjF4OXJHb3EyYVBNdmNCSU5mb1dLUT09?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c183fd18-ee72-4acc-0d77-08da42f5afb5 X-MS-Exchange-CrossTenant-AuthSource: CO6PR12MB5459.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2022 11:07:00.9895 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: g+ZA8htYI3fy5bgbnb9D4mvAwjO6v52z3gehe3L5FKDTU5FL+aI676OiJK0wyqY5YPVsNt7Bngz1Ppg8MPd2hg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3425 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --------------HiPBRcNNH1xVdAKwo421cHEJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/31/22 00:42, Thomas Monjalon wrote: > 07/04/2022 07:30, Xiaoyu Min: >> When application use queue-based flow management and operate the same >> flow on the same queue, e.g create/destroy/query, API for querying aged >> flows should also with queue id parameter just like other queue-based >> flow APIs. > A verb is missing, I am not sure to understand. Ok, I'll re-phrase this. > >> By this way, PMD can work in more optimized way since resources are >> isolated by queue and needn't synchronize. >> >> If application do use queue-based flow management but configure port >> without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate >> the same flow on different queues, the queue id parameter will >> be ignored. >> >> Signed-off-by: Xiaoyu Min >> --- >> doc/guides/prog_guide/rte_flow.rst | 4 +++ >> lib/ethdev/rte_flow.h | 44 ++++++++++++++++++++++++++++++ >> lib/ethdev/rte_flow_driver.h | 7 +++++ >> 3 files changed, 55 insertions(+) >> >> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst >> index 588914b231..d540152d74 100644 >> --- a/doc/guides/prog_guide/rte_flow.rst >> +++ b/doc/guides/prog_guide/rte_flow.rst >> @@ -2963,6 +2963,10 @@ Set ageing timeout configuration to a flow. >> Event RTE_ETH_EVENT_FLOW_AGED will be reported if >> timeout passed without any matching on the flow. >> >> +If queue-based flow rule management is used, when this >> +even is triggered, the ret_param is set to corresponding >> +flow queue. >> + >> .. _table_rte_flow_action_age: >> >> .. table:: AGE >> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h >> index 578dd837f5..9394fb6965 100644 >> --- a/lib/ethdev/rte_flow.h >> +++ b/lib/ethdev/rte_flow.h >> * The flow context and the flow handle will be reported by the >> * rte_flow_get_aged_flows API. >> + * >> + * If queue-based flow rule management is used and port configured with >> + * flag RTE_FLOW_PORT_FLAG_STRICT_QUEUE, RTE_ETH_EVENT_FLOW_AGED event >> + * is triggered with ret_param set to the corresponding flow queue when >> + * a flow queue detects new aged-out flows. > Are you sure it is a good idea to use ret_param for such data? Well, it seems the only way to add queue information without add/change APIs. > ret_param of an event is supposed to be used by the driver > to get a confirmation from the application. > > If the application needs extra info of an event, > it is better to do a separate query like rte_flow_get_aged_flows(). Ok, since the *ret_param* is supposed to be used by driver, then the above approach is not a good idea. So we need a new API, something like rte_flow_get_aged_event_queues(), which will return all flow queues which has the aged flows, right? -Jack > > --------------HiPBRcNNH1xVdAKwo421cHEJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 5/31/22 00:42, Thomas Monjalon wrote:
07/04/2022 07:30, Xiaoyu Min:

When application use queue-based flow management and operate the same
flow on the same queue, e.g create/destroy/query, API for querying aged
flows should also with queue id parameter just like other queue-based
flow APIs.

A verb is missing, I am not sure to understand.
Ok, I'll re-phrase this.


By this way, PMD can work in more optimized way since resources are
isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port
without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate
the same flow on different queues, the queue id parameter will
be ignored.

Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
---
 doc/guides/prog_guide/rte_flow.rst |  4 +++
 lib/ethdev/rte_flow.h              | 44 ++++++++++++++++++++++++++++++
 lib/ethdev/rte_flow_driver.h       |  7 +++++
 3 files changed, 55 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 588914b231..d540152d74 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2963,6 +2963,10 @@ Set ageing timeout configuration to a flow.
 Event RTE_ETH_EVENT_FLOW_AGED will be reported if
 timeout passed without any matching on the flow.
 
+If queue-based flow rule management is used, when this
+even is triggered, the ret_param is set to corresponding
+flow queue.
+
 .. _table_rte_flow_action_age:
 
 .. table:: AGE
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 578dd837f5..9394fb6965 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
  * The flow context and the flow handle will be reported by the
  * rte_flow_get_aged_flows API.
+ *
+ * If queue-based flow rule management is used and port configured with
+ * flag RTE_FLOW_PORT_FLAG_STRICT_QUEUE, RTE_ETH_EVENT_FLOW_AGED event
+ * is triggered with ret_param set to the corresponding flow queue when
+ * a flow queue detects new aged-out flows.

Are you sure it is a good idea to use ret_param for such data?

Well, it seems the only way to add queue information without add/change APIs.

ret_param of an event is supposed to be used by the driver
to get a confirmation from the application.

If the application needs extra info of an event,
it is better to do a separate query like rte_flow_get_aged_flows().

Ok, since the *ret_param* is supposed to be used by driver, then the above approach is not a good idea.

So we need a new API, something like rte_flow_get_aged_event_queues(), which will return

all flow queues which has the aged flows, right?

-Jack
--------------HiPBRcNNH1xVdAKwo421cHEJ--