All of lore.kernel.org
 help / color / mirror / Atom feed
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
Subject: Re: [dpdk-dev] [PATCH v2 0/3] Allow overriding of build-time constants
Date: Mon, 19 Oct 2020 23:04:54 +0200	[thread overview]
Message-ID: <2056495.F7hjc4fSrx@thomas> (raw)
In-Reply-To: <20201019102112.GB649@bricha3-MOBL.ger.corp.intel.com>

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.



  reply	other threads:[~2020-10-19 21:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 11:44 [dpdk-dev] [PATCH 1/2] config: remove explicit undefinition of unset values Bruce Richardson
2020-08-25 11:44 ` [dpdk-dev] [PATCH 2/2] config: allow overriding some build defaults Bruce Richardson
2020-09-01  5:17   ` Ma, LihongX
2020-09-01  6:07     ` Hemant Agrawal
2020-09-01  9:02       ` Bruce Richardson
2020-09-03 14:50       ` Bruce Richardson
2020-09-03 14:49 ` [dpdk-dev] [PATCH v2 0/3] Allow overriding of build-time constants Bruce Richardson
2020-09-03 14:49   ` [dpdk-dev] [PATCH v2 1/3] config: remove explicit undefinition of unset values Bruce Richardson
2020-09-03 14:49   ` [dpdk-dev] [PATCH v2 2/3] config: allow overriding some build defaults Bruce Richardson
2020-09-03 14:49   ` [dpdk-dev] [PATCH v2 3/3] doc: add notes on overriding extra config values Bruce Richardson
2020-09-03 15:43     ` Hemant Agrawal
2020-10-14 14:20   ` [dpdk-dev] [PATCH v2 0/3] Allow overriding of build-time constants Bruce Richardson
2020-10-15  8:55     ` Chen, BoX C
2020-10-15  9:20       ` Bruce Richardson
2020-10-16 15:47   ` David Marchand
2020-10-16 15:55     ` Bruce Richardson
2020-10-16 16:46       ` David Marchand
2020-10-19 10:21         ` Bruce Richardson
2020-10-19 21:04           ` Thomas Monjalon [this message]
2020-10-20  8:34             ` Bruce Richardson
2020-10-20 10:04               ` Thomas Monjalon
2020-10-20 10:15                 ` Bruce Richardson
2020-10-28 16:32   ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2056495.F7hjc4fSrx@thomas \
    --to=thomas@monjalon.net \
    --cc=akhil.goyal@nxp.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=ktraynor@redhat.com \
    --cc=lihongx.ma@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=olivier.matz@6wind.com \
    --cc=stephen@networkplumber.org \
    --cc=talshn@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.