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 B01EFA04DD; Tue, 20 Oct 2020 12:05:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 90E08C872; Tue, 20 Oct 2020 12:05:03 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 7F9EFBE0B for ; Tue, 20 Oct 2020 12:05:01 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 0977E5801D9; Tue, 20 Oct 2020 06:05:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 20 Oct 2020 06:05:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= qFsqSGuRXtsM9GoWXszK8MbIUO/AfLNFm5UeXYlSyIM=; b=lZmfDFvbV9c8qE+J nudsknw1/vCy4mwz0UnpuQmVWxmaQ4rg3nUgPpzqmI3mO6GrGGbuOel09WABf7WT UaZyE3UKl2MRGm48hvP3IjyPPAqeaUJ/vf/7319B4C7MgYFX5vORDxHvka/P8obQ ql7zasvdTxqndjbd5r9CvlIVlg2jqh4QvHuRycVyDKLA9RmyebAPzg3DcjAd8+VY e7WLu+fY/diFJdNvuw58sDrFu7sWERciDh1iaxTOm01VfpvHOXMC5yG+nBqNdETw /aaQOqSvyt8XNCQdUoKelz+OoKZsOifVKmhU0OUXz1UXaW17aSDuNqiZY4He4Acw ZZFfvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qFsqSGuRXtsM9GoWXszK8MbIUO/AfLNFm5UeXYlSy IM=; b=n5NRiccksMYSIoI1lhTF1r1wERHN1PhU1nLMunBWCmSEeJ8QDqHz2vijS j33ZlC5STMRnqROWVRYdFrPm3sJTCMIaPelr3rTEnJJ9cB8X4EDn6CfGPR+uzoDq HkNlLVHwP3/u4KfrO4YNaT8tlgrHuFrfau3mc36Q4k213jw3HxYWrPzdHcPulrcN eu59Hla2ycKm7pcZKYhnufY7wXg3My7gel8HpfhdhY2A68kQ6uQe0FVKESHcd5YL Xhgit22fezYjENtC7sKUiLdBOIfATAPEm1jnozba1HejcEL3Ff6mSsKc4H9ADLmr 1REaXatRB6nq+lkVwBSXjBziqSp9Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeefgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgepudenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D33D328005A; Tue, 20 Oct 2020 06:04:58 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson 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 Date: Tue, 20 Oct 2020 12:04:56 +0200 Message-ID: <1612430.ynYusz7o8J@thomas> In-Reply-To: <20201020083443.GA558@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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.