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 71FAAA04DC; Mon, 19 Oct 2020 12:21:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5B816C9C2; Mon, 19 Oct 2020 12:21:23 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id CF34EC9C0 for ; Mon, 19 Oct 2020 12:21:19 +0200 (CEST) IronPort-SDR: IcOY59BtGXuolql0TccYcGpQX2fQTW392Wr+HzjAdfmnhIIuGDawR0w1HhSuyMFMN+avMZbrio VgtgfeB9fpEw== X-IronPort-AV: E=McAfee;i="6000,8403,9778"; a="146862159" X-IronPort-AV: E=Sophos;i="5.77,394,1596524400"; d="scan'208";a="146862159" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2020 03:21:18 -0700 IronPort-SDR: 7BquzWVI1RZ1BctvJKX2KVdutBzvb5ZuI1SzJ1rMprvXqmHLhVxy4Q2bdC7UftlFqoHuuN1Abb ItS3wxXhagCg== X-IronPort-AV: E=Sophos;i="5.77,394,1596524400"; d="scan'208";a="320220907" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.11.189]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 19 Oct 2020 03:21:16 -0700 Date: Mon, 19 Oct 2020 11:21:12 +0100 From: Bruce Richardson To: David Marchand Cc: dev , Ma Lihong , Hemant Agrawal Message-ID: <20201019102112.GB649@bricha3-MOBL.ger.corp.intel.com> References: <20200825114447.135030-1-bruce.richardson@intel.com> <20200903144942.671870-1-bruce.richardson@intel.com> <20201016155558.GB1121@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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. Third should probably not be exposed at all. /Bruce