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 DBE07457C0; Wed, 14 Aug 2024 13:22:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CB45940E09; Wed, 14 Aug 2024 13:22:29 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) by mails.dpdk.org (Postfix) with ESMTP id CC2D442E7F for ; Wed, 14 Aug 2024 13:22:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723634548; x=1755170548; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=mZf9mrit98W/c0hjnU+anPUX5SssZZ2/JdeXhj36aRU=; b=BjXs0+cCB/QAlJhejzP+Zf075PQdQ17mxczF6lXbBiFSKSJeWKl+E4Iu 8H2bPnMdAZu+pzhbrtUo4iAMkZzB7pq8jy69uLnWaTUx2k7uiM5kxWJvZ uICuQDrcmz2oWSa/5COvIlwAWfDa6Vijv2aqC4F5b6rVSNNR5g0VUe842 Sui+62PR9sR9Na+zrgA8gYxG2yxH1mGVf17p54eaxDDD42J56mSC4lI4S AaQlW0MAoAEsWOCH+1/5fN2viSw4Fi6Ya0MTu+BntSiNsTsxjriKozBqA QhYKPbDu+Qph+GhcJ9V3aRFbE7VmATW+q+rfjTbwzg9xbD3TSy38alG+X A==; X-CSE-ConnectionGUID: xFsb6cQaT4CYUTM6GLk0Ag== X-CSE-MsgGUID: +vEMMQgeR06zLIvxQeTe/g== X-IronPort-AV: E=McAfee;i="6700,10204,11163"; a="32467850" X-IronPort-AV: E=Sophos;i="6.09,145,1716274800"; d="scan'208";a="32467850" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2024 04:22:27 -0700 X-CSE-ConnectionGUID: ExVh24q+S2OnEEAhOKfr5A== X-CSE-MsgGUID: yLK7sdRsRBuBhYxa+Qbpww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,145,1716274800"; d="scan'208";a="63910779" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orviesa004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 14 Aug 2024 04:22:27 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 14 Aug 2024 04:22:26 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 14 Aug 2024 04:22:11 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Wed, 14 Aug 2024 04:22:11 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 14 Aug 2024 04:22:10 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=abo24BpTS/PaLhAXdo99ggqZ4OTB0TZmkWRu7+w8gCpV0e9YcsVJO8KRp93QpiDYZdbd8kQOZS8XEh79Hf6wnBk7EzIbwppb1ShbjgObg8qbQFBjMwLMdSFQwlVt0gUgUFF+o431urls8lwYuJGkZt0XMv5m67ZnEnDrXUR0OLkSNEVGxoKyg/HLve6OorMJqtGge7T5HjnK7/cuKxn40E9/QDdOJaFriM9JjJ5CoBsfTdYquGhfGcKRXe48xvRf2BkvF5eVZrbVxiS4c6S+GHrYunbmSt+RgDIgWz+AzNazs9zm9pMp8UzJN9nfhKo1jGlZCXCnXOZ0Z7JipqJ3dQ== 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=OYwkdkLwVt8or9vpbTKyyAkSRMWXnHacGTyU8tcMD00=; b=DHhxkxNpRjdNWnVGxsqK1wTgWafswxvQvjTm1zDpB67uI2/IUaiq/ChyskAyUoKSG1iKDnk1rgR/lo/4lmIJi91WJTy0XFWWV/Y3YHSA5yqQp5XeBvUNgHooq2g6Gin1tno8K6URYQAq5U8BricKjBUz0QDDfMFy0JzpjCiLtS4zYNsGcmlFGwKvvpZb76BDXdLak/4+iX32PjevL75byh8Nb2gI6geqjYFs/AkY7yJHT7OAooe+GlpknS07m3myFhfVIVE65syVa+q3efenenrbXF4e6cwApqESdVSn31eZkqOEX92HY61ztds2qxLMTnBEyAGz7tyy0p3YwKu+pg== 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 DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.33; Wed, 14 Aug 2024 11:22:07 +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.7875.016; Wed, 14 Aug 2024 11:22:07 +0000 Date: Wed, 14 Aug 2024 12:22:02 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Subject: Re: DPDK configuration options Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35E9F62D@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F62D@smartserver.smartshare.dk> X-ClientProxiedBy: DU2PR04CA0025.eurprd04.prod.outlook.com (2603:10a6:10:3b::30) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|DM4PR11MB6020:EE_ X-MS-Office365-Filtering-Correlation-Id: c82d18a9-cff0-4703-e36e-08dcbc5354fd X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?AEw9kT7qkxYWxAa8IV/VteKFZe+1ZTM3lFvZZ4BXoWrYRUrVmijIUw57UJ?= =?iso-8859-1?Q?U6wyABW3RM2RM9XPd3gDhFS7VSZjvc02FdSL7M/w3+oHyiPoBAq14jsQLt?= =?iso-8859-1?Q?aGMLnFEqxQwYwYKsCLHBH9OKzX3rZEJekyjcq167WZFLcxl6L0TewLhZuS?= =?iso-8859-1?Q?AWb1DDC5wpvqr7HkkwlLIVwADeG6u/FhAaU0LMmdbCGvwAK10xhPLfEW51?= =?iso-8859-1?Q?1oa3R57owmglFz09luPOaEk7meeXkrNOyN9NvtT9e0BbUnLYowAs0WezSy?= =?iso-8859-1?Q?X+aIni65b+WD67hKg4ort58EbMnaoMVwjAwwBDcK/roFNSRHCE5/hmL8WE?= =?iso-8859-1?Q?yQ/KxXct7JQzun0IjD5hCKVEkSd3gJBj09quNCEmNa3GO3vCBab0DQm4SY?= =?iso-8859-1?Q?qvpTmD0gTc3osWg1tYDZc8DCZR6KOghxS4QUvrV7u+ZdYSOWzD0JpknD4g?= =?iso-8859-1?Q?L01egyqs0IDBt8PSGpEfMAfsnjlzTK0qRvHkkSt062+mFm45TkV+BX4bbH?= =?iso-8859-1?Q?1PDO/SoW6fCab9SDBKgy4a7T+u+pHBadvRX9Td5c/n82CvCSOpf5ak331A?= =?iso-8859-1?Q?GE9qNcgtVya2+Iopw+oZvrl+/s9G34+XQpldvLYUrDdzyMBGtQuYYrcvi0?= =?iso-8859-1?Q?R+itpezOf5bBAlrd12Ueeid/61cAMZ7hE5fDZBadEnwH7iUtAgQp1Rde/4?= =?iso-8859-1?Q?xWeCK5Sh0WF/ljHb5cvWjLoQixF3SAwNGI6IY2X7tl2zCzoBftdcuMntbR?= =?iso-8859-1?Q?WNBz1hyno3KKQxMcw+HRZuB3DrxlcpMk1lta9/aQ4x5SHGi2JZq+voZwch?= =?iso-8859-1?Q?ea277ks8j5bll7uzNKWamiBqFIjv5tJ7FUBVW3VDnKl3vczl6nh36w2kET?= =?iso-8859-1?Q?Uk69dvosj9+vDrTOXLBS54NE7Ne58L5cx0PVYGDccfULsECIe9X0Zr46/u?= =?iso-8859-1?Q?Bm3RWVua9uNYPaJkWNdh25I0CQHRHLmT41dg4xjr15zSh3CepezU/7mV86?= =?iso-8859-1?Q?MlIoDVl20c35ewaljw0RzKwkE0Rjpxf+xL6cMa7EaYA7RNWtQ5jIJsoWg4?= =?iso-8859-1?Q?dr9WFHWYaccbkdW3vfoqv59BbErg3qm8rcru7+EGTYGLhklBeEdxkh1sTT?= =?iso-8859-1?Q?dQk2gMjNY4QN62qqwpgXiO3FmyjYE8OA9nWlsxY48AH51VMQfJIBYH1x/I?= =?iso-8859-1?Q?xa1mexLFGO05VY6t45sfrR/5qHWLMw75kwLcBTtuRl/mslaOSG5qhe0geo?= =?iso-8859-1?Q?8tv76trqJYf2VqX7A58a0xZ7/Swc+Y1epUzXEu9MWO0DX32WaAxtRDQ4AB?= =?iso-8859-1?Q?jd+KIFz4hV4fPgQdzPZGW89/HPHx6sA/h5LKEaEVQaa0TKb4UKRtSZCxYW?= =?iso-8859-1?Q?53AkajK4kWypIKaQFfJYcja6b+RUqmpQ=3D=3D?= 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)(376014)(1800799024); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?OpvbfNy1XhgqBpmeZyupZncx8weDxtRyMJ1eABYYIN/mrTOTqBpJBOUgQN?= =?iso-8859-1?Q?SO1rcLL9cjmYWmSgST1WsWCmk+Y9a1lRzskcMuCwWYM6kwccOZvi6lduZx?= =?iso-8859-1?Q?QABJamEyDPRCTWVhLOEbQJw6harwhtzY3fdGNi6Uv/+4qvDe4CYIAxtw91?= =?iso-8859-1?Q?BdaTUF594QOE9/hKh+2BsuqJqBdBuPGGPvgPUh0NK+qbwh6xu6oal2E3Dy?= =?iso-8859-1?Q?A7iKiD1AYgQ9WiAbqEuPohDECM4UdBMibErMDNRdbY76GchoSr351DSaU+?= =?iso-8859-1?Q?IgE76QqP6oyyalZ6tC4cVwCmczukE9tWZWRI2nOFDUmsCMnnkIRrhI6xk9?= =?iso-8859-1?Q?3iJvogBFnDi0sShR7lLHTvny7fdABy3aSsEsbA/Rmea1Wsy1pHN6ubKL6N?= =?iso-8859-1?Q?06y+rqmvdAfzg4ivySYgymKsyxodRbkpawc+YU0f3tjfl17ADu2/ql3pIp?= =?iso-8859-1?Q?tO7ucfP4fLDMRu2NBpHfgwu1PffSm3sdMxp8g2+YKwxJs200KzUi7n0Ai9?= =?iso-8859-1?Q?wvvD/QhLe7jQjZi9Laf2p8+BgKZbpIA04NL6Itwa/qHceVwj+4czX3dE2e?= =?iso-8859-1?Q?FfqTEfwYAWBmU/ff5lJ77XtmTPIXiO4rMaTgoz2h0s1y3Cw+BXvG+mj3fw?= =?iso-8859-1?Q?0/nLLvYxIJr02+XriUieDkypSALHG78b6LEgZci63FmVSL6jXnmLln18Hy?= =?iso-8859-1?Q?R6LeNrcn2PEa3jByBzx5UmuH8xoM/Ksqz80J2cWHzVcxVjP0IsFOQg8r+q?= =?iso-8859-1?Q?DTyBFEVv2U45at+qkFMbxgAMk32D+0P+Y/1L5Py7CcJO+eWDVbFwl2RI1x?= =?iso-8859-1?Q?INZgBYZBEvtUVDsU0KiLcor+qxmaPR+HlBNt72WFr548k7RlO+UPp/CHWT?= =?iso-8859-1?Q?nTwGRooXgbygfN32t/8FdZtWZ5lWZtnbOXjkf64GB4/yCf0F/Mdks/qViy?= =?iso-8859-1?Q?v1WB75WIgITaHNcJbAtpueaflDnm+LlbQDyUlis66UARTQjE4ez+pNQnKJ?= =?iso-8859-1?Q?1tWwnaz9VBFo+fMlhoh5Mv9NTk3tUX+Ak5GZIXUnlkxFq4vEJiY4xW/eX7?= =?iso-8859-1?Q?4IVQh8FFGAMbRXbhxpSNRBuLsGCbXmxfCHSK+dLTqsPHmaGxpUNUBpcomz?= =?iso-8859-1?Q?pmiZyj+HQPHWgbT64Fqt9ybkFG3ZIRLehhXo1/G/rkm64x6ocXizLo1cCj?= =?iso-8859-1?Q?gXV1oj2F6rzLi9GrYHjPNg9rKm7dvVSnrpnPgqvUfBvA8Mk6Y5HXzgUYOq?= =?iso-8859-1?Q?nKcSYK4MfBDMpQFxPNewIq+GGF5cyaOMV/qbt+7Es17EFFgk+xxJynVQkc?= =?iso-8859-1?Q?wwCTgcZu870Bp4/868X4fM3WL7e3C4h0NLbfnFt7fYBbFG9T5H6usCJpGY?= =?iso-8859-1?Q?gBXRncjpy3dKOYK8soHWHpqWujE7Q1UYjvaXI00zESo0kL1reGtj9XXLEQ?= =?iso-8859-1?Q?r9P1YAcfXMJLdmKqEKEIwBuG2MypKaxUnGoSJe2jRtl3UauVbm9qDr35YW?= =?iso-8859-1?Q?OiUY30/KqGMX44URylbbqNQ3aXnbh4JSfcJPu8SM5PMKMqcw06hgJaCP0P?= =?iso-8859-1?Q?/z+z1elrW+XEsT/xAeayQBrovIoEJNrg1Gis2lQ73e8ySMuQ3vxZo8XyAY?= =?iso-8859-1?Q?/uev/mdhOvcyhAS4WaVTYoXWuX9oK9CHqHBIyqYMEozmV0ZW828Rhf3Q?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: c82d18a9-cff0-4703-e36e-08dcbc5354fd X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2024 11:22:07.5808 (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: bhH9SstCt6FqJmDkuI1WGExE41W6YrR6cY6O5rnMcnGp4xfGETTJHlPAg/ALS64HwiQpA7lWLF3b3oEgbYA3BFoJpjW2k465m0uCi125qPY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6020 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 Wed, Aug 14, 2024 at 11:27:58AM +0200, Morten Brørup wrote: > DPDK has many configuration options. > > There are four levels of visibility: > > 1. Some are changed by passing command line options to meson. > 2. Some are changed by modifying their values in config/rte_config.h. > 3. Some are changed by adding them to config/rte_config.h, but you have to magically know of their existence; e.g. RTE_ENABLE_ASSERT, RTE_MALLOC_DEBUG and RTE_LIBRTE_MBUF_DEBUG. > 4. Some are hidden away in drivers, typically driver specific options. > > And many of the configuration options are not even documented anywhere in the code; they are just used by the code. > > It seems the level of visibility is currently determined by how "exotic" the option is considered to be. I think this is the wrong criteria. > > There's also a expectation that a person building DPDK doesn't have to modify config/rte_config.h. I think this is a false expectation; if you are qualified to build DPDK and tweak it along the way, you certainly understand how to modify a header file, and there is no good reason to pass simple configuration values (e.g. max_ethports, mbuf_refcnt_atomic and pkt_mbuf_headroom) 1:1 through meson. > > Furthermore, configuration options should not be hidden away or spread all over the place. It makes them difficult to find and modify. > > Optimally, we would have the same way of configuring DPDK as the Linux kernel. > But I don't see that happening anytime soon. > So, in the interim, we could use one big configuration file, as follows: > > Options that are not candidates for automatic detection at build time should not be level 1, but level 2. (Automatic detection makes sense for e.g. max_lcores, so that should remain at level 1.) > > All level 3 options should be moved to level 2. If there's a configuration option, it should be presented (and documented), not hidden away. Agreed on this. > > Similarly, level 4 options should be moved to level 2; perhaps except options in drivers' "base" directories (code shared by DPDK, Linux and/or other systems). I'm not sure how visible these need to be. If they are driver specific, having them just documented in the specific driver docs is probably good enough. > > Each option should have a comment briefly describing what it does. > Agreed. Taking a step back from the specifics of what options go where, we do need to decide overall how we want to manage build options. For example: * In the past, we had loads of build options in a flag config file, but this turned out to have major issues around validation and didn't seem well liked. * Back when the build system was changed from make to meson/ninja, the general consensus was that we wanted to - as far as possible - move away from build options, because it was impossible to validate all build combinations, and it was very easy to have broken code inside ifdefs that was never even compile-tested. Also, build options didn't work for distro targets, where one build was all that was done. * Since then, though, even though we have had more runtime configurability - we have seen a constant increase in build options too. * Within build options, not all options are equal. For example, numeric values which just affect e.g. array sizes such as number ethdevs, are probably pretty harmless from a testing viewpoint, and may need to be treated differently from build options, e.g. debug ones, which enable/disable code blocks and can therefore introduce subtle issues or hide problems in disabled code. * Within the mechanisms of build options, the main issue I have with using rte_config.h is that it is a file shipped with dpdk and included in the repository. That means that any local changes to it get overwritten with any new DPDK release or update. If we want to have such a file-based approach, I think we need to change things so that we have support for e.g. an rte_config_local.h file which, if present, is used to provide local overrides for the rte_config settings. The exact mechanism by which such a scheme might work I'm not too clear on yet, though! Just my 2c. at this point. /Bruce