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 3158B42414; Thu, 19 Jan 2023 09:44:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BDB9E410DD; Thu, 19 Jan 2023 09:44:57 +0100 (CET) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 9FFA74068E for ; Thu, 19 Jan 2023 09:44:56 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A2A61320090F; Thu, 19 Jan 2023 03:44:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 19 Jan 2023 03:44:55 -0500 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=fm3; t=1674117894; x= 1674204294; bh=C5ne5PtmwJcuGNYzffYQ7S7oiCjl3SuShud0ulJHUtQ=; b=g Zj9f7ImKM587LxshUzUnFLH9mCK3/u86hbpU1gn9BEGrVNIAl9UC8r0VXGsIt1XG p5PDx+lmXEd4ZevjmLUOc/3U/lG+/A41YULkDG7Wm8PdntmFL5UhqNEjWq75hsx7 OarPQTJYmnggG56reIPGYn1wb04T4spXU4q5ufhQ+7vTw936rXI9WwOAuZkI9BVG XCe+QUqtTfjbJ6JtO10VenYoqP1w55FsbngEfxiyfmZvqS4MCeIVLD5BKA5dy+8G nN/ya7iCKCD+gL2WE7x57vJeJLM0bWvZz6Pt4BKrHQsZPD8EaSXpHXSWv1iS+Ng0 +l1lSkZRCDtAyvfIzmtUQ== 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=fm3; t=1674117894; x= 1674204294; bh=C5ne5PtmwJcuGNYzffYQ7S7oiCjl3SuShud0ulJHUtQ=; b=Q gchnW5eloA5fwNimLLyz31rN55tkUktOSETvaqvVCUgj20xhKPP3Y2wuOYDNhTO8 fqj/DdTM+49VWjGt6gBfJDJv2BfgA6sxJW8nGsAkI6dPLYLORzPJMkDuh82tAHMy gmpf2qedU2TQDvc/WGMNYufannvmJ2Vr+0pbeSi0Cetuq9hg4xtWEVEN5hUAganr vlctfoVcn9fll4mdLFxzE1sCr6k0jeHL0voLmDF6qnx6p+CFRnKkis4Ac/cZSP2F i4mp/d7jFserPZkI+pyo5EFjs533U3JsUr34VWjE6DlN6yzW+sN5aZBDaLaD17dP UGJO43w5ObQafExPmT2bA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtledguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Jan 2023 03:44:52 -0500 (EST) From: Thomas Monjalon To: Gregory Etelson Cc: "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh , Ori Kam , Ferruh Yigit , Andrew Rybchenko , "ivan.malov@oktetlabs.ru" Subject: Re: [PATCH v4 1/2] ethdev: add query_update sync and async function calls Date: Thu, 19 Jan 2023 09:44:50 +0100 Message-ID: <2149242.jbyF5MZJ3u@thomas> In-Reply-To: References: <20221221073547.988-1-getelson@nvidia.com> <4220871.e99z0qppnp@thomas> 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 18/01/2023 18:34, Gregory Etelson: > > > Current API allows either query or update indirect flow action. > > > If port hardware allows both update and query in a single operation, > > > application still has to issue 2 separate hardware requests. > > > > > > The patch adds `rte_flow_action_handle_query_update` function call, > > > and it's async version `rte_flow_async_action_handle_query_update` > > > to atomically query and update flow action. > > > > What is the benefit? > > Is it a performance optimization? How much? > > > > rte_flow_action_handle_query_update() can query data and conditionally update it in a single HW operation. > That provides accuracy that cannot be achieved with existing API. > For example, quota flow action must be updated when it in the PASS state only. > If application use existing query, by the time it gets query data and analyzes it, HW object state can change. > As the result application update action will not reflect HW configuration. An explanation of the atomicity benefit should be in the commit log. > The function can provide general optimization, but that was not tested. > > > Application can control query and update order, if that is supported > > > by port hardware, by setting qu_mode parameter to > > > RTE_FLOW_QU_QUERY_FIRST or RTE_FLOW_QU_UPDATE_FIRST. > > > > > > RTE_FLOW_QU_QUERY and RTE_FLOW_QU_UPDATE parameter values > > provide > > > query only and update only functionality for backward compatibility > > > with existing API. > > > > Why do we need such compatibility? > > The existing functions will stay, isn't it? > > > > rte_flow_action_handle_query_update() has extended functionality with better HW support. You cannot argue HW support without knowing what would be the support of other vendors. > The plan is to deprecate and replace existing query and update functions. I disagree with such deprecation. Anyway it is not the topic of this patch, so I suggest to remove the sentence about compatibility.