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 7DEBFA0542; Mon, 30 May 2022 18:42:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 69EF440689; Mon, 30 May 2022 18:42:30 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 868DD400D6 for ; Mon, 30 May 2022 18:42:28 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 323A55C00EE; Mon, 30 May 2022 12:42:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 30 May 2022 12:42:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1653928948; x= 1654015348; bh=ISywzhSdoO5M9sEuQROuOorbC8sXDQo80QHGTcEjCXk=; b=u OmwkBWigLk7d/umpW+0iN+LAYIXm7eKxN1Adkp5bKAG/mezRiA/E7DN9wa3wFJLe 7Wgq/pagqboFZtmxCZpJFYjbHdJ1yLK05Fb2BtqK+S6flefMmuyQZ8TsNaACUMLm 2rytiSuQIv4jphgtWLBAzzMkfuCLtQIpYpkhPoAt0LKeH3R8FtURikORVzs6eUl/ 5LtxU4SVBBGlqGuMd7B6Lv8HBn5ze2t+feE+K0cHay2H4XK6c/FpnGhHDfFg3cux 1FFdv4KO+22bG9hZvnF8o3MewH5j6mEIHbgp3kOkPgrFTsJfUSTgUHiCwK1rFHvM CTAliE1gHZ3L22AoBvSlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1653928948; x= 1654015348; bh=ISywzhSdoO5M9sEuQROuOorbC8sXDQo80QHGTcEjCXk=; b=v jxhOazCaobnGRW66pmpvmMiDwJrKmDgSCJP6M7FLaxT+W7oypk0jBeAr/0Vaq/Ut Unk+qsIhjDbwJeO3LP1pLLamVuiAq22xwH0Vw7B66oTT8VMNi/57CdKapD/Rv3JU XBI5hvfyR6yJeJELEAWRGY4qqvnGdrUOKUz2+MBDdCiWFaeuUEvHVuWG4Rdw2a2Z 1chhKiCiOnZSQwTMc0uQ/u/IsCF2saUVCRIqfGWzjQaDoYo2NyHtYd4WlyryQWFA 9j8D8bEMbFM2hgu09ljTCl1XvIX4g/NlF5a7Rd1517Q5pUVofh/Pl0q0RYa2HHSz HcQ6C6/Z0vF5MOhnfopLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrkeeigddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 May 2022 12:42:26 -0400 (EDT) From: Thomas Monjalon To: Xiaoyu Min Cc: Ori Kam , Ferruh Yigit , Andrew Rybchenko , dev@dpdk.org Subject: Re: [RFC 2/2] ethdev: queue-based flow aged report Date: Mon, 30 May 2022 18:42:24 +0200 Message-ID: <2183304.iZASKD2KPV@thomas> In-Reply-To: <9b673505092754dca22df7939cc009930864b45c.1649308627.git.jackmin@nvidia.com> References: <9b673505092754dca22df7939cc009930864b45c.1649308627.git.jackmin@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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. > 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? 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().