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 C4828459D7; Thu, 19 Sep 2024 17:09:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A846C4338A; Thu, 19 Sep 2024 17:09:01 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by mails.dpdk.org (Postfix) with ESMTP id E55EF406FF for ; Thu, 19 Sep 2024 17:08:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1726758539; x=1758294539; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=sEagN9g4y8xQQZcvFc3ca4mBZLVbIxIvcasDK7WJjgA=; b=Rbdmil2qfervrzCEvtMGev6jX6MNGP6fszjHqAiM2v+fHjdayPxq9s15 ZfI1HqSk7JQLmIzDa25sWFph4nqStzlwQhrkmgaLYNHUqBaSXWtl+MBwe Ri2O7k5Bj4xa2ghyX3KY550FtQQQV69+KxK/8cgP/fQE52CVpAQEEKHfa JQ3/TXOIDjsrMZzUd/8P38TmRNblFwBaPk0ur1+QlQtCsMckghv6LOpga Bkg4PM5+BzwdSDR85jWe8M7zs8uvf+8fqYcw4olWiVZphJBTFwrQwyun9 Mm/DDLHTo1P7jEbAIgCvuC7OBNbmalRqC+i4PgIzFD1H0nsgueJht+JLg Q==; X-CSE-ConnectionGUID: O4MPH7zYTgKMgQ/5JQpa5w== X-CSE-MsgGUID: uQZcWycCT+OiBAxXNnMd5g== X-IronPort-AV: E=McAfee;i="6700,10204,11200"; a="13593663" X-IronPort-AV: E=Sophos;i="6.10,242,1719903600"; d="scan'208";a="13593663" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Sep 2024 08:08:58 -0700 X-CSE-ConnectionGUID: FPKjbtZ7T+im5MeTyB1Kfg== X-CSE-MsgGUID: 73AeTvABRQOBiqJ0/FWCJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,242,1719903600"; d="scan'208";a="100798394" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmviesa001.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 19 Sep 2024 08:08:53 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 19 Sep 2024 08:08:51 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Thu, 19 Sep 2024 08:08:50 -0700 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.41) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 19 Sep 2024 08:08:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TIqOx3A3sQGXM1qNUdP3EcBv0+qFrkN1NJPsj+neS1eKkDPlrY1aszqz8d8Q2HYvXOiX6TgI/JWvMbKo06iN1p6eGn9o6NZBeOZRv7wcxUwcn+nHRxgtSNG/s9ZoTU4WvObjsAT9kKs5xLegIhoc0dgguI3/JRqUYaU8TVwEdEznSNJdmkbO2kJunBqzri1uwb7STQT2Ft/mSWP9t/Ciw/uv/JZMb6laMePL7wG8EYtFx7tJckdMwtmwZXrVn726zNejExQQANfrBGTjhvJgYAyPEXd7em4fedl1pqbT+1IctQyBv0lfrY2+/qvWfruzG5RJ429hk50UryzHGqjtiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=sVbHfGONLx7OuPYOCKuGX20gukAh8RuacnSX6H3oQ3o=; b=Ud5Dt9ZIxImL5kpRbL5U/qcKF9uvCQwOVVYDPjwFx6quIVDMig2Bygd/l7DebtoQj+mQSg1so4P60CH8JHtzQg4lLjnBj23CHQauizKtooCJV/w466XzsEcwcHn2KDVQHI9xDmveaH7mNgiUeX/3QS6Z7JAA1XugZGjkYOwdl6gfbkKS6m2sag6l62IhUEAC72XgXPw3FH/Y55MbsFszTE+sN7V2fjDi/ykhOI7IMn8o+5pyGXl43a091k3VIRm0d07SeD2syfLeM+X5hfPgCgxwuawVD93qr/r6IqPKtxaqsYGEHhcFdjslN4EGuun9IDINpKgwg5sgrXq9L1QVIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by DS0PR11MB6374.namprd11.prod.outlook.com (2603:10b6:8:ca::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7962.24; Thu, 19 Sep 2024 15:08:39 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b%2]) with mapi id 15.20.7982.012; Thu, 19 Sep 2024 15:08:36 +0000 Date: Thu, 19 Sep 2024 16:08:29 +0100 From: Bruce Richardson To: David Marchand CC: , , , Subject: Re: [PATCH v3 00/26] add meson config options for queues per port Message-ID: References: <20240812132910.162252-1-bruce.richardson@intel.com> <20240814104933.14062-1-bruce.richardson@intel.com> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: DU2P250CA0022.EURP250.PROD.OUTLOOK.COM (2603:10a6:10:231::27) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|DS0PR11MB6374:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f3704c6-7577-44ba-03b2-08dcd8bcef99 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?cFphWU4rTlJZL0FhMUkzWThMYm9UamE3b0lwQ1M5Q1R0VWdpVXczVW4wMDc5?= =?utf-8?B?OU85VjFIOFcyNWh6MTFMcnhrZCszeTJzS0tpNzlDOEkvSHE5UHhUa21aazRx?= =?utf-8?B?NXNraXRYRWY2UzEyRFduZk85Q3crTDdZR21ISENwZE41Qm9aRW42N1hjWGwz?= =?utf-8?B?cGUrbW9HK1RoRENXSUVlKzJZajk5NXpzelBwa2VOOU5ZM2FaVTI5MjhyK2pN?= =?utf-8?B?bUh3c1BsVDdDekpGM3Y1Mi9qWEF6WkNqUmlVSjljWmpwZkFnWVphYUlWdTdY?= =?utf-8?B?NVpoSEZvaTJaU1Exbk1hWlRLbmhRV2d4SE5sTG1yWHd5eklaUlR5ajVhRFdx?= =?utf-8?B?d1owRjlVbkRkcmt4OHhrNFN5QXRpbWpOUEh0VS9RQVR2Q2poZjhuMVhhRzFm?= =?utf-8?B?YVF3dEpRZHc1YUdUQzZ2RVBpRHphWkFhNVNWY2dFUnAvWklIajBMbWNRV1ZB?= =?utf-8?B?L1l6aW9pckx6YjlhUWxySkVIV2I0elk2SXd0WEpxdGc4d3JWWXBBQ013UTYy?= =?utf-8?B?WXdQdko4L2I2WWxRa0JScUlNKzZhZTlzajlKTm1UMGxBNlE5L2hOSHdDbzBm?= =?utf-8?B?Q2tCdWN4d2VoUFVTK3ZHd3lQQzMwTW5LZVFlVGI2SmMycVlhK2R5bE9qMHlo?= =?utf-8?B?bDk2N3hnSWZJT3duL0JJMlRvNnFqcktGUS9nYkZsWkRQelI0L2xtVE5NU0lh?= =?utf-8?B?ZFVlVWlSWUZxQk15SmZxdUNWTThFSEJRU1cvQzhoWi9QWkhyYzZzaVFLWkhN?= =?utf-8?B?M2tXMk8xYitEdUw5VW1rMnlQd2MvcHpadFBrOG1uWnFnUjhHaGVackoyWmtF?= =?utf-8?B?blFPVW9FM0VVMVBCc1NvNGErWnV0dXBTM3RaWUo5WGZLMUMxcjJDUzJxeUkz?= =?utf-8?B?ZUM4TmNEM0orZTRDWmNLblpmNU9DRUNtdkxnbkh0OWlJWlA0QkFsVm10M2d5?= =?utf-8?B?cmllNG00L3JidXJyRWFwZ3M4MXpyTWJBdGRxZk43MTFkNXZkd0g2TDcyczQw?= =?utf-8?B?Z3RXRHFHSXhMWnVnTGVlbnhoMitsQ000QjlsQi9HUUZ3RDZIRmdJbDcrTmw4?= =?utf-8?B?WTRDRTA1TndBUU92YnBxR1NEZjRHbmlqWnVSNFpKWmxRSjZ6THFFU0p2Z3pj?= =?utf-8?B?ZmZycUt2UzNDSkpyMFR2cDdKK2lidTFLa1R2UFZKVDh5UHIzSEdDbmdWd1RJ?= =?utf-8?B?dVpTWE1xTHdGYkkvQWsyekFEZ3lydWNXYWpGc2wvZVNRMW9aUmN2b1FmcHY0?= =?utf-8?B?b0dvWHJzY0RhdkpOdEhXcVRGMG5Ba3pNTTRDblZ3WlpOTVczdVhHZmZ2V3kv?= =?utf-8?B?b2s3QThIeUNiMXlLZmdPN2xWWTRySkE1TUlDSWVKMVBQS2VZb0FZNWMyRDlp?= =?utf-8?B?L0dRYnp6N3RqL3dGdDJEUUhsR25FNUpHNUI1a2QzLzRvMTcxbXJva0JFbTVF?= =?utf-8?B?a0E2dEtvTTNBcjArQ2RPTWZMb2NVcUd5ZGZLNWJBTm9VZzNPd3FoaDROYW94?= =?utf-8?B?czZCemF2cmo0Rm80VTV6cjhuWS9ORnYwRlhUZXB2OGFMcmtiK3NkRDNPQjEy?= =?utf-8?B?TUprWGFWK21jZTU3UGZPOUNxTGVrN0VuamlRL0tLZ2prWktkUEhSQmFZcXRj?= =?utf-8?B?TjJTa25SZXFaL095cXRhTUVmNllTaHF2eUo0THNHWnI0THU4UFhvL3lNZFA0?= =?utf-8?B?czF4WGdEOTJBM2RoQnJ3Ym8vK2xOa0hGZ1R4YjlvengvODVZOS9ndDJRMXB0?= =?utf-8?B?WTZhQUtLTGNvVGhVSWFuc0NzM1Q4Zkx3djJLYXIwQkhXWkRkaGd2U2MzNHdn?= =?utf-8?B?aGcvQjZ6QndNS21BU05ZZz09?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NFRkYTBTMXBoT0h6QkJCYVA3YW4rS1pFNDRvQ1B0ZWJMbDJCdFUvYnRLcWh2?= =?utf-8?B?NWNZMUt6ZnpISlN4enBuV3A4anhjNllnd2N6VXprUVlpVjVEbWhTcnQwMkxH?= =?utf-8?B?djdZaGFNeVU3RStHaTQ1WVpEdGZjc2hZa2NOUGV3WXRzVmJVYmRyRGxpRkpn?= =?utf-8?B?a2pYbzVqNUpkR0pzd0tyWTBuSlEvaEg4NkdZSkk1K0ErMGZSOFpJYmNscW5W?= =?utf-8?B?NE9JUWJsMjdnMGozQ05PcE5xcTQ0eStqRW0rekJyVkNtZThZclZPcUR6UHJK?= =?utf-8?B?emtlQWRrYVZtUWNCUUM2bEsreXVKUllBQitXeitJeWNOVVduMFdIVEdySmxx?= =?utf-8?B?dW0zc05jWG1WT20ybjVvZStlSVhFNk1uMEgvSDExZFJ5aDRzbStRZ0t3cWF3?= =?utf-8?B?a0RRaExWQUVBd05PUWk1TjE2ZVNHc2tReWdJY3VRWS8yN2daTndTbkVwV3FV?= =?utf-8?B?UVZQQTFMbXdoSzU1MDEveERrbXd5TXR4YnBMR0lkVW5UVDBrVUFxZEpaeWlj?= =?utf-8?B?ZGpGekRRV1RzanZhNGJmYzNudmNpbG4yQ1J6eXp3NGhzUU0wV203RnlxdkVh?= =?utf-8?B?TWNzN2dVNUtTNnhFdVhhVXQ1K1RmSHFtQWZ6TDJzdnhSWFplQnl3NlRKR2Fn?= =?utf-8?B?WVU4dVplOGkrUk9CcmdMWU1oam5GRHFDV0Z5RWlRNGJLcXAzdVQybyt0dUI1?= =?utf-8?B?cWhQOEYzcDJSZEtObUVJRUhKVE96L1RQYVB1V3FhbHh0ZGM0a0xMbk9URzZr?= =?utf-8?B?amNyc2NFV25OeExocnBLeVZNVVBKWHladEoxM01EVzZRdlp0Q1VZQXozZzRI?= =?utf-8?B?OW9LS1pjMTh2UXNJUUtLWU4wc2FmOFBDLzJuSjR2eHFvM05zeUhpV0lkSjli?= =?utf-8?B?ZVpqWmYzS3JWOVpKVU8rcTZBL2kzM1R3TXkxWmdlSnRnZWVYYTc3YzZ6Q1NW?= =?utf-8?B?dTQwby9jUUVoTWkzcmc5UFpQSU84MlRoZ3VsQ3cwcVJuZDlsVW1Xc0tkS25W?= =?utf-8?B?cTNOb24zNGhDNjlweUs3MCt5THEybmIybkVSTmV4elNvdjd4bStrLzZSYjd3?= =?utf-8?B?RkhNNFlnVzh4dnlSMnExaFV5TjhqV0FhSGo4eXFPeHMvWWI3V3R3MVpheDU4?= =?utf-8?B?RTVCRFFSKzgxSURwOGlFYm9MN00zSUE5Y0hDWFB5RmZBNVROb1RDWE9IeWVz?= =?utf-8?B?cWZocXVPMW5nL3hYbndzOUhjdndTWE9TblB6c3RMMC90YVppZGxrRTh6WWta?= =?utf-8?B?cEhFTnFzM0c3aFBxV3RnU0EyTWtpeTZRcmx0dVZKcUNQcXNzMGhBOWJHQ1R3?= =?utf-8?B?NFQ5bFdTdlNrNjBwOWlIMG9LZ0lqTjBhRzUxRlI5WGc0bXJFYm5mMitVZW1o?= =?utf-8?B?TGRsK0hrdmxoTklTMG41anoyN28wR01TL3NIVnd4eEpieVRCMlNJQ09NUS9Y?= =?utf-8?B?MVE5ZVZjTElPalZPRFZPa2oySVRZd1BhT0JLOHMwU0VVa2JuU2cva3duMk9m?= =?utf-8?B?Wk5NNWNQa2RUalkzb2Z1Tm9DSFl3M2FyYm10VTVzcUdlNTBPc2QrZUlFVGE3?= =?utf-8?B?TXExM2xTOWZpNWpHMGtQd2Vwa3JRRkhPNW5mMFRRbXFoWmM0Wlc5NlZDNFlq?= =?utf-8?B?ei9mZE9taDVYOHFiaUNaOGdaeXJTTndlWk82UGtDdWZ2elBjaGRlMmJScGZB?= =?utf-8?B?cktyS2tpR21vNEFuWWwyOXMyY1EzVStpanZzaDdGUk40eSsrM0NJLzBTY1RR?= =?utf-8?B?Q21mMXpwQ1A0M3FDdVcvVjRCUnVVWlIvWjZNNW5uNnhHUnhjQW1Od2RYblAw?= =?utf-8?B?K2plRFA5MjlEU2syb2drR3ZEMHcvQ2NVVzZoS0hJUEFuVng5dGd5T0M5MVFa?= =?utf-8?B?cDM4UmNQVWFZb1p0NEhCeWxrbks2cWs2WFBNdjFsNmNwckkzbm4xNlpsSzIv?= =?utf-8?B?TUVOV0NXR0wyTktncUhLaCtTODN5emF0cXd3bFRzNEZUdGVudm51b1FETHI2?= =?utf-8?B?cnE2d05JV3ZEcHlhbUdmaU5JS1cxdTNQR1R6bjYwa1ZObnltenF0Y2hMYlJX?= =?utf-8?B?OUhZeTR2ZlN5R3Y3VWZ3YXJZR0U4TmJlREg1ZE93VlNwdko2a2x1ZlNlaGNP?= =?utf-8?B?bGVsQnF2azRta1NXdmNEZGg0dThUaS8xT3J4WDdHWmtQd2VuaWEyWFI1VW5r?= =?utf-8?B?TWc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 4f3704c6-7577-44ba-03b2-08dcd8bcef99 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2024 15:08:36.7470 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: gHjatFckD91xXYu3iTJRSIOlZTf8dlL/6kCgfxIWgduNHi8YkKcS7RYQ2l8P5HVPjClxdwvn5oG6HhQZwW3ZYz1I15MmP8I7AY9+oNMBM9k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB6374 X-OriginatorOrg: intel.com 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 Thu, Sep 19, 2024 at 04:14:28PM +0200, David Marchand wrote: > On Wed, Aug 14, 2024 at 12:50 PM Bruce Richardson > wrote: > > > > There are a number of issues with the current RTE_MAX_QUEUES_PER_PORT > > setting in DPDK that are addressed by this patchset: > > > > * The name does not make it clear that this is intended as an > > ethdev-only setting > > * A number of other libraries are using this define rather than having > > more relevant defines for the particular usecase. > > * The define is hard-coded in DPDK source code and is not adjustable via > > a build-time/meson option > > * Because of the lack of configurability, the max is therefore set to a > > conservatively-high value, wasting memory. > > * There is an assumption that the number of Rx queues and Tx queues > > should have the same maximum value. Depending on application, it may > > be desirable to have fan-in with multiple Rx queues e.g. for > > classification/filtering, feed a single Tx queue, or the opposite > > where, e.g. for QoS Tx scheduling, a few Rx queues feeds a very large > > number of Tx queues. > > > > This patchset therefore addresses these by: > > > > * replacing the single define for max queues with independent defines > > for Rx and Tx queues. > > * adjusts the name to ensure that it is clear the defines are for > > ethports only. [ethports being used in the RTE_MAX_ETHPORTS setting]. > > * replaces occurances of RTE_MAX_QUEUES_PER_PORT with appropriate > > defines for non-ethdev use cases > > * replaces all other internal occurances of the define with the new > > per-Rx and per-Tx definitions. > > * adds meson config options to allow build-time configuration of the max > > Rx and Tx queue values. > > > > Naming Note: > > * The new meson config options are called "max_ethport_rx_queues" and > > "max_ethport_tx_queues" so that in the meson options list they appear > > alphabetically beside the existing "max_ethports" option. > > * For naming consistency, the new C defines are therefore > > RTE_MAX_ETHPORT_RX_QUEUES and RTE_MAX_ETHPORT_TX_QUEUES. > > > > V3: > > * Resend of v2 with correct author email, to avoid reply bounces > > * drop "rfc" prefix from patches > > > > V2: > > * What was a single patch with "3 insertions(+), 1 deletion(-)" has now > > become a 26-patch set! :-) > > * Created separate Rx and Tx defines > > * Ensured that the name makes it clear that the define is for ethdev > > * When updating internal use, created one patch per component for easier > > maintainer review. In most cases it was obvious whether Rx or Tx > > define should be used, but a few cases were less clear. > > * Added documentation updates for the changes (release notes and > > deprecation notice), spread across 3 of the patches. > > > > Bruce Richardson (26): > > cryptodev: remove use of ethdev max queues definition > > eventdev: remove use of ethev queues define > > app/test-bbdev: remove use of ethdev queue count value > > config: add separate defines for max Rx and Tx queues > > ethdev: use separate Rx and Tx queue limits > > bpf: use separate Rx and Tx queue limits > > latencystats: use separate Rx and Tx queue limits > > pdump: use separate Rx and Tx queue limits > > power: use separate Rx and Tx queue limits > > net/af_xdp: use separate Rx and Tx queue limits > > net/cnxk: use separate Rx and Tx queue limits > > net/failsafe: use separate Rx and Tx queue limits > > net/hns3: use separate Rx and Tx queue limits > > net/mlx5: use separate Rx and Tx queue limits > > net/null: use separate Rx and Tx queue limits > > net/sfc: use separate Rx and Tx queue limits > > net/thunderx: use separate Rx and Tx queue limits > > net/vhost: use separate Rx and Tx queue limits > > app/dumpcap: use separate Rx and Tx queue limits > > app/test-pmd: use separate Rx and Tx queue limits > > examples/ipsec-secgw: use separate Rx and Tx queue limits > > examples/l3fwd-power: use separate Rx and Tx queue limits > > examples/l3fwd: use separate Rx and Tx queue limits > > examples/vhost: use separate Rx and Tx queue limits > > config: make queues per port a meson config option > > config: add computed max queues define for compatibility > > > > app/dumpcap/main.c | 2 +- > > app/test-bbdev/test_bbdev.c | 4 ++-- > > app/test-pmd/testpmd.c | 7 ++++--- > > app/test-pmd/testpmd.h | 16 ++++++++-------- > > config/meson.build | 10 ++++++++++ > > config/rte_config.h | 2 +- > > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++ > > doc/guides/rel_notes/release_24_11.rst | 21 +++++++++++++++++++++ > > drivers/net/af_xdp/rte_eth_af_xdp.c | 2 +- > > drivers/net/cnxk/cnxk_ethdev_ops.c | 4 ++-- > > drivers/net/failsafe/failsafe_ops.c | 4 ++-- > > drivers/net/hns3/hns3_tm.c | 2 +- > > drivers/net/mlx5/mlx5_flow.c | 2 +- > > drivers/net/mlx5/mlx5_flow_hw.c | 2 +- > > drivers/net/null/rte_eth_null.c | 4 ++-- > > drivers/net/sfc/sfc_sw_stats.c | 6 ++++-- > > drivers/net/thunderx/nicvf_ethdev.c | 2 +- > > drivers/net/vhost/rte_eth_vhost.c | 7 ++++--- > > examples/ipsec-secgw/ipsec-secgw.c | 2 +- > > examples/ipsec-secgw/ipsec.c | 2 +- > > examples/l3fwd-power/main.c | 2 +- > > examples/l3fwd-power/perf_core.c | 2 +- > > examples/l3fwd/main.c | 2 +- > > examples/vhost/main.c | 2 +- > > examples/vhost/main.h | 2 +- > > lib/bpf/bpf_pkt.c | 3 ++- > > lib/cryptodev/cryptodev_pmd.c | 4 ++-- > > lib/ethdev/ethdev_driver.h | 8 ++++---- > > lib/ethdev/ethdev_private.c | 24 ++++++++++++++---------- > > lib/ethdev/rte_ethdev.c | 16 +++++++--------- > > lib/ethdev/rte_ethdev.h | 18 +++++++++--------- > > lib/eventdev/eventdev_private.c | 2 +- > > lib/latencystats/rte_latencystats.c | 4 ++-- > > lib/pdump/rte_pdump.c | 18 +++++++++--------- > > lib/power/rte_power_pmd_mgmt.c | 4 ++-- > > meson_options.txt | 4 ++++ > > 36 files changed, 140 insertions(+), 87 deletions(-) > > > > I sent some comments. > > Patch 2 has a typo "ethev" in its title. Sure. Will do a new revision in future if others are similarly ok with it. > > I would squash the drivers changes into a single patch, as those are mechanical. > Yep, makes sense. I split them out for easier review. Are you or Thomas ok to squash those on apply as I'd rather keep them separate for maintainers while the changes are still in patchwork? > The last two patches may have to be squashed as I suspect compilation > is broken for applications relying on RTE_MAX_QUEUES_PER_PORT if we > stop between the two changes. Yes, good point that it might be. Will squash in later revisions. > > Otherwise, lgtm. > One open question is whether we are doing the right thing to have separate defines for Tx queues and Rx queues? I think it's useful to have the separate defines, but there has been a comment suggesting that we are better keeping the single define. My own thinking is that the single-define is appropriate for offload devices since the queues tend to come in pairs - since everything sent down to the device comes back up again - but for the NICs, we can have wild assymmetry depending on use case, for example, for QoS on Tx. I take it you are ok with the two-define solution then? /Bruce