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 8B91AA0032; Thu, 17 Feb 2022 09:18:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5F68840150; Thu, 17 Feb 2022 09:18:10 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 07FD240042 for ; Thu, 17 Feb 2022 09:18:09 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 48A665801D5; Thu, 17 Feb 2022 03:18:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 17 Feb 2022 03:18:07 -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; bh=ie+5TduZ2SpPIy +b+I94APKYHgkdZYKmoKZZ7EyUsCI=; b=ClHdd6F1YOBtwMY+z1vhBZXd4UPmmg IXcxEufkFz+b5V3rhRp10d2qvsKQi8Anyspdi662SsEERbiuPUARsOkqW7fmseeY BRPLxZVdgA14JKp3oo/Z6XMcvaCKYJu8oHTP1T7e1HKTvZmvd4HtQHthD/NqfDvj gmvjO7fWdI6sk1BFyRLMq7XeHfP34Ib/v2HWz1GKOjdr5yRmAi+aRKmupueERTfu UbwbQQjSCl4XQj/anu+uwgQQ+VBhB4M0VeXtSL7VvYcb7Zgq+QhAQHp4i7NDXpqi Qx2fdCrexKYqnU654fCYuuCyWxBhRvZ0CL0hTCDjHnRkM8W6OQ3MdNuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ie+5TduZ2SpPIy+b+I94APKYHgkdZYKmoKZZ7EyUs CI=; b=ltCSLQt64RoFS4zErr0khKwBJTeV2pmA0PqCUq3rup3AjU5BCya60OziA ACPiucfX6z12NHHbktWgydcd6n0x0ZMWf35p2A9ydp7cVlreVrcEEC+WRmVVk+A1 FPqNGbtfKISgCOqKS9FF49Wzb9xUAdXg3t4PTE9FRao4wWSTWrXnAUMQyuIlWJta 5O/jkrLpoohhQh2z6B6avROJjdSS3CSg5tRP4JcBH1qBQZoWH55xAafK1y0XMls3 atandmEN1xx4GnU+SkohNxHY4m+gghHB/2UKZG57KttrvnbtkCsd9DRJMAoH2zAR EJSnhBMJBHonFrcmTkjODtr9k7qVg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjeejgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Feb 2022 03:18:04 -0500 (EST) From: Thomas Monjalon To: Ori Kam Cc: Andrew Rybchenko , "dev@dpdk.org" , "ivan.malov@oktetlabs.ru" , "ferruh.yigit@intel.com" , "mohammad.abdul.awal@intel.com" , "qi.z.zhang@intel.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , "bruce.richardson@intel.com" , Alexander Kozyrev Subject: Re: [PATCH v5 03/10] ethdev: bring in async queue-based flow rules operations Date: Thu, 17 Feb 2022 09:18:02 +0100 Message-ID: <1799960.R1toDxpfAE@thomas> In-Reply-To: References: <20220209213809.1208269-1-akozyrev@nvidia.com> <3214274.KgjxqYA5nG@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 16/02/2022 23:49, Alexander Kozyrev: > On Sat, Feb 12, 2022 4:25 Thomas Monjalon wrote: > > 12/02/2022 03:19, Alexander Kozyrev: > > > On Fri, Feb 11, 2022 7:42 Andrew Rybchenko > > : > > > > On 2/11/22 05:26, Alexander Kozyrev wrote: > > > > > +__rte_experimental > > > > > +struct rte_flow * > > > > > +rte_flow_q_flow_create(uint16_t port_id, > > > > > > > > flow_q_flow does not sound like a good nameing, consider: > > > > rte_flow_q_rule_create() is > > ___ > > > > > > More like: > > > ___ > > > ___ > > > Which is pretty lengthy name as for me. > > > > Naming :) > > This one may be improved I think. > > What is the problem with replacing "flow" with "rule"? > > Is it the right meaning? > > I've got a better naming for all the functions. What do you think about this? > Asynchronous rte_flow_async_create and rte_flow_async_destroy functions > as an extension of synchronous rte_flow_create/ rte_flow_destroy API. > The same is true for asynchronous API for indirect actions: > rte_flow_async_action_handle_create; > rte_flow_async_action_handle_destroy; > rte_flow_async_action_handle_update; > And rte_flow_push/rte_flow_pull without "_q_" part to make them clearer. > And yes, I'm still thinking pull is better than poll since we are actually retrieving > something, not just checking if it has something we can retrieve. > Let me know if we can agree on this scheme? Look pretty close to existing one. I like the "async" word. In summary, you propose this change for the functions of this patch: rte_flow_q_flow_create -> rte_flow_async_create rte_flow_q_flow_destroy -> rte_flow_async_destroy rte_flow_q_action_handle_create -> rte_flow_async_action_handle_create rte_flow_q_action_handle_destroy -> rte_flow_async_action_handle_destroy rte_flow_q_action_handle_update -> rte_flow_async_action_handle_update rte_flow_q_push -> rte_flow_push rte_flow_q_pull -> rte_flow_pull They are close to the exisiting synchronous function names: rte_flow_create rte_flow_destroy rte_flow_action_handle_create rte_flow_action_handle_destroy rte_flow_action_handle_update I think it is a good naming scheme.