All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Ophir Munk <ophirmu@nvidia.com>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, Matan Azrad <matan@nvidia.com>,
	Lior Margalit <lmargalit@nvidia.com>,
	Asaf Penso <asafp@nvidia.com>,
	david.marchand@redhat.com, honnappa.nagarahalli@arm.com,
	jerinj@marvell.com
Subject: Re: [PATCH v1] config: make max memzones definition configurable
Date: Mon, 13 Feb 2023 14:55:41 +0100	[thread overview]
Message-ID: <3111936.fEcJ0Lxnt5@thomas> (raw)
In-Reply-To: <Y+oZiHYdAu8vfLvd@bricha3-MOBL.ger.corp.intel.com>

13/02/2023 12:05, Bruce Richardson:
> On Sun, Feb 12, 2023 at 10:53:19AM +0200, Ophir Munk wrote:
> > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard
> > coded as 2560.  For applications requiring different values of this
> > parameter – it is more convenient to set its value as part of the meson
> > command line rather than changing the dpdk source code per application.
> > An example would be of an application that uses the DPDK mempool library
> > which is based on DPDK memzone library.  The application may need to
> > create a number of steering tables, each of which will require its own
> > mempool allocation.
> > This commit adds a meson optional parameter named max_memzones. If not
> > specified - it is set by default to 2560. The hard coded definition of
> > RTE_MAX_MEMZONE is removed. During meson build time the RTE_MAX_MEMZONE
> > can be optionally defined as the value of max_memzones parameter.
> > 
> > Signed-off-by: Ophir Munk <ophirmu@nvidia.com>
> > ---
> > RFC:
> > https://patchwork.dpdk.org/project/dpdk/patch/20230130092302.376145-1-ophirmu@nvidia.com/
> > 
> >  config/meson.build  | 1 +
> >  config/rte_config.h | 1 -
> >  meson_options.txt   | 2 ++
> >  3 files changed, 3 insertions(+), 1 deletion(-)
> > 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Are we going to move all compilation-defined settings to meson_options.txt?
The direction discussed in recent years was to configure things at runtime,
and stop adding compilation-time settings.

In this case, it is quite easy to add a new function
	void rte_memzone_set_max(int max)
to be called before rte_eal_init().
If not called, the historical default is used.



  reply	other threads:[~2023-02-13 13:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-12  8:53 [PATCH v1] config: make max memzones definition configurable Ophir Munk
2023-02-13 11:05 ` Bruce Richardson
2023-02-13 13:55   ` Thomas Monjalon [this message]
2023-02-13 14:52     ` Bruce Richardson
2023-02-13 17:04       ` Ophir Munk
2023-02-21 10:28         ` Thomas Monjalon

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=3111936.fEcJ0Lxnt5@thomas \
    --to=thomas@monjalon.net \
    --cc=asafp@nvidia.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=lmargalit@nvidia.com \
    --cc=matan@nvidia.com \
    --cc=ophirmu@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.