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 90338A00BE; Fri, 11 Feb 2022 11:22:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6292B4270A; Fri, 11 Feb 2022 11:22:10 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id A285C41144 for ; Fri, 11 Feb 2022 11:22:09 +0100 (CET) Received: by shelob.oktetlabs.ru (Postfix, from userid 115) id 398177E; Fri, 11 Feb 2022 13:22:09 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mail1.oktetlabs.ru X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_DISCARD, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 Received: from bree.oktetlabs.ru (bree.oktetlabs.ru [192.168.34.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPS id 979A85D; Fri, 11 Feb 2022 13:22:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 979A85D Authentication-Results: shelob.oktetlabs.ru/979A85D; dkim=none; dkim-atps=neutral Date: Fri, 11 Feb 2022 13:22:08 +0300 (MSK) From: Ivan Malov To: Ferruh Yigit cc: Alexander Kozyrev , dev@dpdk.org, orika@nvidia.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, mohammad.abdul.awal@intel.com, qi.z.zhang@intel.com, jerinj@marvell.com, ajit.khaparde@broadcom.com, bruce.richardson@intel.com Subject: Re: [PATCH v4 00/10] ethdev: datapath-focused flow rules management In-Reply-To: <245157e3-1948-f207-9cdd-88ce22cad453@intel.com> Message-ID: <3ca5edd4-37b9-8448-d41c-38157afeab9c@oktetlabs.ru> References: <20220206032526.816079-1-akozyrev@nvidia.com > <20220209213809.1208269-1-akozyrev@nvidia.com> <245157e3-1948-f207-9cdd-88ce22cad453@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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 Hi Ferruh, On Thu, 10 Feb 2022, Ferruh Yigit wrote: > On 2/9/2022 9:37 PM, Alexander Kozyrev wrote: >> Three major changes to a generic RTE Flow API were implemented in order >> to speed up flow rule insertion/destruction and adapt the API to the >> needs of a datapath-focused flow rules management applications: >> >> 1. Pre-configuration hints. >> Application may give us some hints on what type of resources are needed. >> Introduce the configuration routine to prepare all the needed resources >> inside a PMD/HW before any flow rules are created at the init stage. >> >> 2. Flow grouping using templates. >> Use the knowledge about which flow rules are to be used in an application >> and prepare item and action templates for them in advance. Group flow rules >> with common patterns and actions together for better resource management. >> >> 3. Queue-based flow management. >> Perform flow rule insertion/destruction asynchronously to spare the >> datapath >> from blocking on RTE Flow API and allow it to continue with packet >> processing. >> Enqueue flow rules operations and poll for the results later. >> >> testpmd examples are part of the patch series. PMD changes will follow. >> >> RFC: >> https://patchwork.dpdk.org/project/dpdk/cover/20211006044835.3936226-1-akozyrev@nvidia.com/ >> >> Signed-off-by: Alexander Kozyrev >> Acked-by: Ori Kam >> >> --- >> v4: >> - removed structures versioning >> - introduced new rte_flow_port_info structure for rte_flow_info_get API >> - renamed rte_flow_table_create to rte_flow_template_table_create >> >> v3: addressed review comments and updated documentation >> - added API to get info about pre-configurable resources >> - renamed rte_flow_item_template to rte_flow_pattern_template >> - renamed drain operation attribute to postpone >> - renamed rte_flow_q_drain to rte_flow_q_push >> - renamed rte_flow_q_dequeue to rte_flow_q_pull >> >> v2: fixed patch series thread >> >> Alexander Kozyrev (10): >> ethdev: introduce flow pre-configuration hints >> ethdev: add flow item/action templates >> ethdev: bring in async queue-based flow rules operations >> app/testpmd: implement rte flow configuration >> app/testpmd: implement rte flow template management >> app/testpmd: implement rte flow table management >> app/testpmd: implement rte flow queue flow operations >> app/testpmd: implement rte flow push operations >> app/testpmd: implement rte flow pull operations >> app/testpmd: implement rte flow queue indirect actions >> > > Hi Jerin, Ajit, Ivan, > > As far as I can see you did some reviews in the previous versions, > but not ack the patch. Thanks for sending the reminder. Yes, I did review the series. During the review, we did not find a common ground with regard to possibly having a universal "task enqueue" method. However, I was assured that such design would affect performance. > Is there any objection to last version of the patch, if not I will > proceed with it. Personally, I have no strong objections. The v5 series seems a lot clearer in a number of ways, yet, it is going to be experimental, so I believe that if we run into some issues with this deisgn, we will still have a chance to improve it to some extent. In general, the author did a very good job applying that many review notes. Thanks to Alexander for perseverance. Please feel free to proceed with the series as you see fit. > > > Hi Alex, > > As process we require at least one PMD implementation (it can be draft) > to justify the API design. > > If there is no objection from above reviewers and PMD implementation > exists before end of the week, I think we can get the set for -rc1. > > Thanks, > ferruh > -- Ivan M