Message ID | 20220209213809.1208269-1-akozyrev@nvidia.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 90A55A0032; Wed, 9 Feb 2022 22:38:36 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 26A3A41101; Wed, 9 Feb 2022 22:38:36 +0100 (CET) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2068.outbound.protection.outlook.com [40.107.244.68]) by mails.dpdk.org (Postfix) with ESMTP id B936040140 for <dev@dpdk.org>; Wed, 9 Feb 2022 22:38:34 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bkUVciBTbKjWiTcIduAGNW2CRjgr4IFYKgjL0D4uGzthtMxLF2SyHK9ZX3H6H0QmQFh2s1uKyn72P+N66UYm6SZXZamjsYUpLR0QGQTppXhBl/QIcvYISfmKLak95/kBPBUZCAQBQZZ0OGykQW7xxQ2t6oL6KzXYnMtypuXuSys3W2Idh/zOLgCOp9sD2uxn52irosc0knrdRDHxgHEpT3TQ4J4wkgKDuyk5ZjtUSYyFC0C4EkYooBUhN1vpfHr9YBsITRFakyIIoSNZ0NJ7Z+8vouFCOML3D5pCd9HDEMljGSiYqtYIpI3Orz3OdxMsxgiROWLu2rxeKkpF9KU7iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fmy+rzUx+Qch6L4RFMbJsjMQyM/YOXu/E9yqrXp5h9U=; b=BgiZsCzlF3qQ1lAY9aGFqYdAPl+yf3C2KDN4DFW0M2Rp7tD7H7E/quYgPaMjU+ZVwALVfX53huQ2PRxL35Oqbt6QeIZBJvaYNN7HWQi1fIvToUYEhK2knN2eoMiudDjQ2YUPIEEn15d7pEBaQbdMuXTJSFEpjkT1PfwZvpsIeleT9D/VIaXaj1NjYawbx9K9jmVscUTKS1LfcK5bnf/MUCzc1KGYwp7GBn2VW2dzv4+EdJ1mcSlFnmsmSLcmdk3eL5fnbzbGcxItTKdcmU7PE5twBdWaznLDnd580SuYGQM43rXxZPP2OzcGQndBkgu7zDRInWMha2pz15HLdZEhQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 12.22.5.238) smtp.rcpttodomain=intel.com smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fmy+rzUx+Qch6L4RFMbJsjMQyM/YOXu/E9yqrXp5h9U=; b=WA7jX03GdjrQDSnYWYNG+eKhtOzXK3pyg4kjK/JLC2CbL5qQiy5w/pXCjKbW0PMPTeKF/6s3xwy43ncXPUaAY6rx3w6li+D0AAE/SbBxCGw3VbbEreuC0afjFnyE9dfijw5i8fmE5XBEYw/Kuh6KBWmgMfRlP4CrqLLGwvw2Jj7IAcbj15wdqbUipo515wdQ/B4eh/wjwxqUhJKUSekbcdCtEgV/nxppHHgrKRTay8ujmzjDThxfmDgEGsI58jxJPvqnk4C+/RW0Q8NowMSZt2sIFzDuPnynRTqAhdpN3obSxRwZY9tYQ0MuRNqs+eXHCXIccEBwsnH/RqZ4Uo/Lbg== Received: from CH2PR12MB4230.namprd12.prod.outlook.com (2603:10b6:610:aa::23) by BYAPR12MB4981.namprd12.prod.outlook.com (2603:10b6:a03:10d::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Wed, 9 Feb 2022 21:38:32 +0000 Received: from BN6PR14CA0028.namprd14.prod.outlook.com (2603:10b6:404:13f::14) by CH2PR12MB4230.namprd12.prod.outlook.com (2603:10b6:610:aa::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 9 Feb 2022 21:38:31 +0000 Received: from BN8NAM11FT018.eop-nam11.prod.protection.outlook.com (2603:10b6:404:13f:cafe::3b) by BN6PR14CA0028.outlook.office365.com (2603:10b6:404:13f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12 via Frontend Transport; Wed, 9 Feb 2022 21:38:31 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 12.22.5.238) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 12.22.5.238 as permitted sender) receiver=protection.outlook.com; client-ip=12.22.5.238; helo=mail.nvidia.com; Received: from mail.nvidia.com (12.22.5.238) by BN8NAM11FT018.mail.protection.outlook.com (10.13.176.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4975.11 via Frontend Transport; Wed, 9 Feb 2022 21:38:31 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by DRHQMAIL105.nvidia.com (10.27.9.14) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 9 Feb 2022 21:38:30 +0000 Received: from pegasus01.mtr.labs.mlnx (10.126.231.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.9; Wed, 9 Feb 2022 13:38:27 -0800 From: Alexander Kozyrev <akozyrev@nvidia.com> To: <dev@dpdk.org> CC: <orika@nvidia.com>, <thomas@monjalon.net>, <ivan.malov@oktetlabs.ru>, <andrew.rybchenko@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> Subject: [PATCH v4 00/10] ethdev: datapath-focused flow rules management Date: Wed, 9 Feb 2022 23:37:59 +0200 Message-ID: <20220209213809.1208269-1-akozyrev@nvidia.com> X-Mailer: git-send-email 2.18.2 In-Reply-To: <20220206032526.816079-1-akozyrev@nvidia.com > References: <20220206032526.816079-1-akozyrev@nvidia.com > MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.126.231.35] X-ClientProxiedBy: rnnvmail202.nvidia.com (10.129.68.7) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 97669311-cadf-4e38-1a64-08d9ec148462 X-MS-TrafficTypeDiagnostic: CH2PR12MB4230:EE_|BYAPR12MB4981:EE_ X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr,ExtAddr X-Microsoft-Antispam-PRVS: <CH2PR12MB42307D20560C5B365F6BEE9EAF2E9@CH2PR12MB4230.namprd12.prod.outlook.com> X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +n5CKVP3VGaiGAIXsVkgEk6BLIkEBNYEBux+NSGUmQvSqlOEqJ4Mb6sSeuvlKKScFm7ocIFtFRj7nG0ZlXPGom0hxi2NqCeSaofeHBni4TpT/h9HwQzYqjyDWGRFbzhmvt4bEzgXalj9G2VLiVSmrnTS+WZO6PfC/sb98wXErT6J3Xyv+3ZPiqu2YarcBJJmVXj3bOFYRrguHgE+ziIAJvgpUh1KopeFiS/xpwbzFFUPpVtwx/uZyc0QE6qKlp6w54MvQWFk44/uN6Iwi54j/121Xk09TolxvC32Wi+JBvB4+GdicMlZS6Ii8Yeo1Ahd6T4yB4oUz1P8isMTQdJrIebQh9EUQx8WHe9hBCkIcSlRyjADK3zMWDnkOwLAxagCj3V3F5kY6bSukiFXoOO0NYuIiU++XSs2fh8SPtpl24nU9EeG2Tmnxxw8culi61Mcu8YQFoUzTyhwzRO9WWwG20DQMwfb0OgT53wX/S4P8WHHPoN7LWkaOHo1hTI+cpPi4POR40/+xcYitpS8B80LKhsz5vJaMYZAJs0vqDtEaL7RZq5gdSqzImXaA33M+dbYj4RJG1u5Woo4nBgWmE1hSKZuDql/CXll6dJqpDsjNQehPvSr6y1owMZeutXBFK8CYotRY8PUdOLkXK/h4er3JHkNbnJwSqGndXFJsCHrGb2BvtOwG7lnifk0gY+Ur7ny6gmcOEayiVh1d0GuW/RSjGOEKVoRdxbanklvNeD+Uqr1J0n9bVK+Fw4P409C6K87UFiOqUOsV+kGrp0kWa3eP2q/xPGUtoGtVaoKtrbJcQE= X-Forefront-Antispam-Report: CIP:12.22.5.238; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:mail.nvidia.com; PTR:InfoNoRecords; CAT:NONE; SFS:(13230001)(4636009)(36840700001)(46966006)(40470700004)(508600001)(83380400001)(6666004)(40460700003)(1076003)(966005)(5660300002)(2616005)(47076005)(36756003)(8936002)(356005)(6916009)(82310400004)(186003)(26005)(16526019)(54906003)(70206006)(70586007)(86362001)(8676002)(426003)(4326008)(81166007)(316002)(7416002)(36860700001)(336012)(2906002)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2022 21:38:31.2440 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 97669311-cadf-4e38-1a64-08d9ec148462 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[12.22.5.238]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT018.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB4981 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org |
Series |
ethdev: datapath-focused flow rules management
|
|
Message
Alexander Kozyrev
Feb. 9, 2022, 9:37 p.m. UTC
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 <akozyrev@nvidia.com> Acked-by: Ori Kam <orika@nvidia.com> --- 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 app/test-pmd/cmdline_flow.c | 1496 ++++++++++++++++- app/test-pmd/config.c | 771 +++++++++ app/test-pmd/testpmd.h | 66 + doc/guides/prog_guide/img/rte_flow_q_init.svg | 205 +++ .../prog_guide/img/rte_flow_q_usage.svg | 351 ++++ doc/guides/prog_guide/rte_flow.rst | 326 ++++ doc/guides/rel_notes/release_22_03.rst | 22 + doc/guides/testpmd_app_ug/testpmd_funcs.rst | 378 ++++- lib/ethdev/rte_flow.c | 359 ++++ lib/ethdev/rte_flow.h | 702 ++++++++ lib/ethdev/rte_flow_driver.h | 102 ++ lib/ethdev/version.map | 15 + 12 files changed, 4773 insertions(+), 20 deletions(-) create mode 100644 doc/guides/prog_guide/img/rte_flow_q_init.svg create mode 100644 doc/guides/prog_guide/img/rte_flow_q_usage.svg
Comments
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 <akozyrev@nvidia.com> > Acked-by: Ori Kam <orika@nvidia.com> > > --- > 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. Is there any objection to last version of the patch, if not I will proceed with it. 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
Thanks, Ferruh. The pmd part is being updated according to the previous API comments. @Suanming Mou is working on it and will send it once ready, before the weekend. Regards, Asaf Penso >-----Original Message----- >From: Ferruh Yigit <ferruh.yigit@intel.com> >Sent: Thursday, February 10, 2022 6:00 PM >To: Alexander Kozyrev <akozyrev@nvidia.com>; dev@dpdk.org >Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) ><thomas@monjalon.net>; ivan.malov@oktetlabs.ru; >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 > >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 <akozyrev@nvidia.com> >> Acked-by: Ori Kam <orika@nvidia.com> >> >> --- >> 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. >Is there any objection to last version of the patch, if not I will proceed with it. > > >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
Hi, I wish the PMD part is not too late. You can find the series here: https://patches.dpdk.org/project/dpdk/cover/20220210162926.20436-1-suanmingm@nvidia.com/ Thanks, Suanming Mou > -----Original Message----- > From: Asaf Penso <asafp@nvidia.com> > Sent: Friday, February 11, 2022 12:12 AM > To: Ferruh Yigit <ferruh.yigit@intel.com>; Alexander Kozyrev > <akozyrev@nvidia.com>; dev@dpdk.org; Suanming Mou > <suanmingm@nvidia.com> > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) > <thomas@monjalon.net>; ivan.malov@oktetlabs.ru; > 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 > > Thanks, Ferruh. > The pmd part is being updated according to the previous API comments. > @Suanming Mou is working on it and will send it once ready, before the > weekend. > > Regards, > Asaf Penso > > >-----Original Message----- > >From: Ferruh Yigit <ferruh.yigit@intel.com> > >Sent: Thursday, February 10, 2022 6:00 PM > >To: Alexander Kozyrev <akozyrev@nvidia.com>; dev@dpdk.org > >Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) > ><thomas@monjalon.net>; ivan.malov@oktetlabs.ru; > >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 > > > >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 <akozyrev@nvidia.com> > >> Acked-by: Ori Kam <orika@nvidia.com> > >> > >> --- > >> 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. > >Is there any objection to last version of the patch, if not I will proceed with it. > > > > > >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
On Thu, Feb 10, 2022 at 8:00 AM Ferruh Yigit <ferruh.yigit@intel.com> 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 <akozyrev@nvidia.com> > > Acked-by: Ori Kam <orika@nvidia.com> > > > > --- > > 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. > Is there any objection to last version of the patch, if not I will > proceed with it. The latest set is looking good. There are some places where we could cleanup or rephrase the text. But that need not block the series. So for the series Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Thanks for checking. > > > 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
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 <akozyrev@nvidia.com> >> Acked-by: Ori Kam <orika@nvidia.com> >> >> --- >> 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
On Thu, Feb 10, 2022 at 9:30 PM Ferruh Yigit <ferruh.yigit@intel.com> 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 <akozyrev@nvidia.com> > > Acked-by: Ori Kam <orika@nvidia.com> > > > > --- > > 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. > Is there any objection to last version of the patch, if not I will > proceed with it. Personally, I have no strong objections. Based on the top level review, It looks good to me on the application API side. 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