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 97132A00BE; Thu, 17 Feb 2022 12:02:44 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D3514114E; Thu, 17 Feb 2022 12:02:44 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 903704114B for ; Thu, 17 Feb 2022 12:02:42 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 2B05144; Thu, 17 Feb 2022 14:02:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 2B05144 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1645095761; bh=jVPf1NLeRxsPTtPla3mf8QEXCDZxUSczf2QpDorE/vg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lyU/Run1lvhq5lqKHtY2qtYDsGGUB15ah/s639jLcHVa4vp2Dv7wWP6jl6KOWnmc4 o7tlBJzOItDl/gLl+pDPYLeF8Tt3QLVeMjCJoqYp6O2XHFikBvczgV+mdpL7tMkbUy M7OIJNFIZSG9HGiNl8/vnR7DL+2Cnr30VqNThKCM= Message-ID: Date: Thu, 17 Feb 2022 14:02:40 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 03/10] ethdev: bring in async queue-based flow rules operations Content-Language: en-US To: Thomas Monjalon , Ori Kam Cc: "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 References: <20220209213809.1208269-1-akozyrev@nvidia.com> <3214274.KgjxqYA5nG@thomas> <1799960.R1toDxpfAE@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <1799960.R1toDxpfAE@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 2/17/22 11:18, Thomas Monjalon wrote: > 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. +1