From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1EC3EA04DC;
	Mon, 19 Oct 2020 23:05:10 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 6AAB2C972;
	Mon, 19 Oct 2020 23:05:07 +0200 (CEST)
Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com
 [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id EEA01C932
 for <dev@dpdk.org>; Mon, 19 Oct 2020 23:05:04 +0200 (CEST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
 by mailnew.nyi.internal (Postfix) with ESMTP id 91C605804B9;
 Mon, 19 Oct 2020 17:05:01 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Mon, 19 Oct 2020 17: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=
 WkGgHmSTI/1DBM30w2UZYF8FhuOuE8k+uy3W2alsb4k=; b=Ohf2JPT7+LjdejFy
 p09oFUnxNCiHbjpfruYoNB8U4LCpAY8/g/v4CULcjWGWT7RWEBl1BpImr9x+OK+4
 jZgithxoKYE3K60/+Bp43kKzQS/c1LC9kB47lLXhjw8io1N477wqjS7jKCC7igwM
 TH4iBe5YUr9ghiXUfS1GzN/rXqmsp2F+34IL451HjKXSUjTfp/87V8AuH4sZJywI
 gcLQ5p41HOPgMNEX9nMb5rw8UwDtg8rHky+iE2PEIrL2IP8qpkCybEBngy+JFxDh
 kdOadwLNG8xCGCl8GeHBtJw7Sw8UEKOr7rStl7jryv2VDLM0tHDNadaIta9pq1uH
 7ebbcw==
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=WkGgHmSTI/1DBM30w2UZYF8FhuOuE8k+uy3W2alsb
 4k=; b=D5gBX6PqnOUQVgCwu9+CGqoO7qS5zwRo9GZT9sH4F5qaTbv29t1fnNfYU
 ixl9kpbXu0+gPd/93dt+GCeLUvBsu1HQpjk2AbtF+GweEFDIHkg800rzrDDGzAUs
 OKD79mrFypdxJ4MFs3fQ7kwYgwU2pzgUkiJgN2vUNoMIa1cMf/fCMybeJkmRli+y
 TUigaFIdkLONbVYDOlHLyLuDfqH3Mm+v+XGTWH+G6W0b1JvnnlphY1169gBqNlzS
 B6IFyumAISFgVy+bhHuBGBOGdftAZmZcKUDEfDph/aGvcdHwnzNk0vubQRioaVL8
 td/z6Y12xg2OyA75bh0TdYHdy5/tQ==
X-ME-Sender: <xms:fP-NX_d6puLFdH8L4TjSdicHSaltM12lUUm7jklPIF_-crB7MCutpw>
 <xme:fP-NX1NhBunKxp_gaGLqdBM3YbTv728JZDkbGDo3w3cxz6PYQKGCHosopNXq5velH
 MGLxifjFbBMJpvvPw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjedvgddvudcutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
 frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
 iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih
 iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho
 nhdrnhgvth
X-ME-Proxy: <xmx:fP-NX4haDJ2ZXB0IVrBuvzlgKtoBTE90mV1rBRvQ3Xl9Ti8X0he0xw>
 <xmx:fP-NXw8o3KG1YSrDGs520mnsGRN4wXZp1D9CYh78TdTScnzBwVI_lg>
 <xmx:fP-NX7tM0uKmOr1VUtdxhnSrZNGhSmVFCfsEOaqaMJ-puRS_XVr7qg>
 <xmx:ff-NX7H63yLjPpiURZZWeCmtpntxMfzVjKtsW92hL9mZFjSRaWUsPg>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id C8BFE3064682;
 Mon, 19 Oct 2020 17:04:58 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: David Marchand <david.marchand@redhat.com>, dev@dpdk.org,
 Ma Lihong <lihongx.ma@intel.com>, Hemant Agrawal <hemant.agrawal@nxp.com>,
 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: Mon, 19 Oct 2020 23:04:54 +0200
Message-ID: <2056495.F7hjc4fSrx@thomas>
In-Reply-To: <20201019102112.GB649@bricha3-MOBL.ger.corp.intel.com>
References: <20200825114447.135030-1-bruce.richardson@intel.com>
 <CAJFAV8ziDDa2oCr5phai4gZPR6JnETovEJ+HCtyVonfiS99MpQ@mail.gmail.com>
 <20201019102112.GB649@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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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
> > <bruce.richardson@intel.com> 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?

> 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.