From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3A593A04DD; Tue, 20 Oct 2020 12:15:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 911FBBCFB; Tue, 20 Oct 2020 12:15:52 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id DD1D1BCF5 for ; Tue, 20 Oct 2020 12:15:50 +0200 (CEST) IronPort-SDR: P2DzWbpB9DmmSUAM1ExNvUqGXhO6dlAl9f2dBtyKlkSSx8ZzFh8mwm4umAPh4TxkYhx/TWd0Tf HIJMPfpfy2bQ== X-IronPort-AV: E=McAfee;i="6000,8403,9779"; a="228817051" X-IronPort-AV: E=Sophos;i="5.77,396,1596524400"; d="scan'208";a="228817051" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2020 03:15:46 -0700 IronPort-SDR: 3bKE0gTO1L/+7wkw30mBfZGDXUuS1b0Cn97XV0dnYzOlqKSz8aIVRdQgdRa6otWplBi9Nt1P2C QBXpSJIDG7xQ== X-IronPort-AV: E=Sophos;i="5.77,396,1596524400"; d="scan'208";a="523451734" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.248.1]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 20 Oct 2020 03:15:43 -0700 Date: Tue, 20 Oct 2020 11:15:39 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: David Marchand , dev@dpdk.org, Ma Lihong , Hemant Agrawal , ktraynor@redhat.com, maxime.coquelin@redhat.com, olivier.matz@6wind.com, jerinj@marvell.com, stephen@networkplumber.org, honnappa.nagarahalli@arm.com, andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com, akhil.goyal@nxp.com, talshn@nvidia.com, dmitry.kozliuk@gmail.com, bluca@debian.org Message-ID: <20201020101539.GD558@bricha3-MOBL.ger.corp.intel.com> References: <20200825114447.135030-1-bruce.richardson@intel.com> <2056495.F7hjc4fSrx@thomas> <20201020083443.GA558@bricha3-MOBL.ger.corp.intel.com> <1612430.ynYusz7o8J@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1612430.ynYusz7o8J@thomas> Subject: Re: [dpdk-dev] [PATCH v2 0/3] Allow overriding of build-time constants X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Oct 20, 2020 at 12:04:56PM +0200, Thomas Monjalon wrote: > 20/10/2020 10:34, Bruce Richardson: > > On Mon, Oct 19, 2020 at 11:04:54PM +0200, Thomas Monjalon wrote: > > > 19/10/2020 12:21, Bruce Richardson: > > > > On Fri, Oct 16, 2020 at 06:46:12PM +0200, David Marchand wrote: > > > > > On Fri, Oct 16, 2020 at 5:56 PM Bruce Richardson > > > > > wrote: > > > > > > > librte_eal.so is indeed built with the 64 value: $ pahole -C > > > > > > > rte_mem_config build/install/lib64/librte_eal.so |grep > > > > > > > memsegs die__process_function: tag not supported (INVALID)! > > > > > > > struct rte_memseg_list memsegs[64]; /* 136 > > > > > > > 8704 */ > > > > > > > > > > > > > > > > > > > > > But no trace of the custom value for external applications: $ > > > > > > > grep -r RTE_MAX_MEMSEG_LISTS build/install > > > > > > > build/install/include/rte_config.h:#ifndef > > > > > > > RTE_MAX_MEMSEG_LISTS > > > > > > > build/install/include/rte_config.h:#define > > > > > > > RTE_MAX_MEMSEG_LISTS 128 Binary file > > > > > > > build/install/lib64/librte_eal.a matches Binary file > > > > > > > build/install/lib64/librte_eal.so.21.0 matches > > > > > > > > > > > > > > I can see the same using the meson option -Dc_args. > > > > > > > > > > > > Good point, I had not thought of external apps using these > > > > > > values. > > > > > > > > > > > > They are mostly for internal use, so maybe its worthwhile > > > > > > looking to not have them in a public header file. What do you > > > > > > think? Is it likely that apps would be using some of these > > > > > > values, or needs to know the specifics? > > > > > > > > > > Some are publicly exposed, like RTE_MEMPOOL_CACHE_MAX_SIZE, > > > > > RTE_PKTMBUF_HEADROOM, RTE_ETHDEV_RXTX_CALLBACKS, For those, > > > > > either we propagate the overriden value to the installed > > > > > rte_config.h or we refuse customisation. > > > > > > > > > I'd suggest the first 2 of those should possibly be global meson > > > > options. > > > > > > How the application is reading the meson options? > > > > > The meson options are reflected in the rte_build_config.h file. It's > > not automatic, but they should be set there by the config/meson.build > > file. If some are missed, they can be added, but I disagree that all > > meson options should always be passed through to apps. It makes them > > part of the API, perhaps unnecessarily, and therefore harder to change > > or adjust. Furthermore why should an app ever need to care if a DPDK > > build included the docs, or the kmods? > > > > > > Third should probably not be exposed at all. > > > > > > I think everything should be exposed. The application may need to > > > know whether a feature is enabled or not, and what is a specific > > > tuning value. > > > > > > I suspect it is the last blocker for meson adoption. Now that we > > > removed the makefiles, we need to fill this gap urgently. > > > > > I really don't see this as a gap. With "make" we struggled with massive > > amounts of build config, and we tried to remove as much as we can. > > While this is reporting what's there rather than tweaking it, surely > > many of these settings are just better as #defines in the individual > > header files - if they need to be exposed at all. > > I agree with the goal of moving these #defines internally. I just feel > having wrong values in rte_config.h looks to be a bug. > Oh agree, absolutely! The other attitude to take (and document) here is that if someone is going to the trouble to override the default DPDK value when building DPDK they also need to provide that CFLAG when building their app too. If they don't want that, they need to adjust the value in the code directly.