From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Ophir Munk <ophirmu@nvidia.com>,
dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,
Devendra Singh Rawat <dsinghrawat@marvell.com>,
Alok Prasad <palok@marvell.com>, Matan Azrad <matan@nvidia.com>,
Lior Margalit <lmargalit@nvidia.com>
Subject: Re: [RFC] lib: set/get max memzone segments
Date: Thu, 20 Apr 2023 11:20:43 -0700 [thread overview]
Message-ID: <20230420182043.GA30650@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <4891070.0VBMTVartN@thomas>
On Thu, Apr 20, 2023 at 09:43:28AM +0200, Thomas Monjalon wrote:
> 19/04/2023 16:51, Tyler Retzlaff:
> > On Wed, Apr 19, 2023 at 11:36:34AM +0300, 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 the max value via an rte API -
> > > rather than changing the dpdk source code per application. In many
> > > organizations, the possibility to compile a private DPDK library for a
> > > particular application does not exist at all. With this option there is
> > > no need to recompile DPDK and it allows using an in-box packaged DPDK.
> > > An example usage for updating the RTE_MAX_MEMZONE 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 is not about how to optimize the application usage of
> > > mempool nor about how to improve the mempool implementation based on
> > > memzone. It is about how to make the max memzone definition - run-time
> > > customized.
> > > This commit adds an API which must be called before rte_eal_init():
> > > rte_memzone_max_set(int max). If not called, the default memzone
> > > (RTE_MAX_MEMZONE) is used. There is also an API to query the effective
> > > max memzone: rte_memzone_max_get().
> > >
> > > Signed-off-by: Ophir Munk <ophirmu@nvidia.com>
> > > ---
> >
> > the use case of each application may want a different non-hard coded
> > value makes sense.
> >
> > it's less clear to me that requiring it be called before eal init makes
> > sense over just providing it as configuration to eal init so that it is
> > composed.
>
> Why do you think it would be better as EAL init option?
> From an API perspective, I think it is simpler to call a dedicated function.
> And I don't think a user wants to deal with it when starting the application.
because a dedicated function that can be called detached from the eal
state enables an opportunity for accidental and confusing use outside
the correct context.
i know the above prescribes not to do this but.
now you can call set after eal init, but we protect about calling it
after init by failing. what do we do sensibly with the failure?
>
> > can you elaborate further on why you need get if you have a one-shot
> > set? why would the application not know the value if you can only ever
> > call it once before init?
>
> The "get" function is used in this patch by test and qede driver.
> The application could use it as well, especially to query the default value.
this seems incoherent to me, why does the application not know if it has
called set or not? if it called set it knows what the value is, if it didn't
call set it knows what the default is.
anyway, the use case is valid and i would like to see the ability to
change it dynamically i'd prefer not to see an api like this be introduced
as prescribed but that's for you folks to decide.
anyway, i own a lot of apis that operate just like the proposed and
they're great source of support overhead. i prefer not to rely on
documenting a contract when i can enforce the contract and implicit state
machine mechanically with the api instead.
fwiw a nicer pattern for doing this one of framework influencing config
might look something like this.
struct eal_config config;
eal_config_init(&config); // defaults are set entire state made valid
eal_config_set_max_memzone(&config, 1024); // default is overridden
rte_eal_init(&config);
ty
next prev parent reply other threads:[~2023-04-20 18:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 8:36 Ophir Munk
2023-04-19 8:48 ` Ophir Munk
2023-04-19 13:42 ` [EXT] " Devendra Singh Rawat
2023-04-24 21:07 ` Ophir Munk
2023-04-19 14:42 ` Stephen Hemminger
2023-04-24 21:43 ` Ophir Munk
2023-04-19 14:51 ` Tyler Retzlaff
2023-04-20 7:43 ` Thomas Monjalon
2023-04-20 18:20 ` Tyler Retzlaff [this message]
2023-04-21 8:34 ` Thomas Monjalon
2023-04-21 11:08 ` Morten Brørup
2023-04-21 14:57 ` Thomas Monjalon
2023-04-21 15:19 ` Morten Brørup
2023-04-25 16:38 ` Ophir Munk
2023-04-25 13:46 ` Ophir Munk
2023-04-25 16:40 ` [RFC V2] " Ophir Munk
2023-05-03 7:26 ` [PATCH V3] " Ophir Munk
2023-05-03 21:41 ` Morten Brørup
2023-05-25 6:47 ` Ophir Munk
2023-05-04 7:27 ` David Marchand
2023-05-25 6:35 ` Ophir Munk
2023-05-18 15:54 ` Burakov, Anatoly
2023-05-25 6:43 ` Ophir Munk
2023-05-24 22:25 ` [PATCH v4] " Ophir Munk
2023-05-25 14:53 ` Burakov, Anatoly
2023-05-30 11:37 ` Ophir Munk
2023-05-26 9:55 ` David Marchand
2023-05-28 12:09 ` [EXT] " Alok Prasad
2023-05-30 13:32 ` Thomas Monjalon
2023-05-31 7:56 ` Ophir Munk
2023-05-31 7:52 ` [PATCH V5] " Ophir Munk
2023-05-31 8:41 ` [PATCH V6] " Ophir Munk
2023-06-05 8:52 ` [PATCH V7] " Ophir Munk
2023-06-05 10:50 ` [PATCH V8] " Ophir Munk
2023-06-05 16:50 ` 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=20230420182043.GA30650@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=roretzla@linux.microsoft.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dsinghrawat@marvell.com \
--cc=lmargalit@nvidia.com \
--cc=matan@nvidia.com \
--cc=ophirmu@nvidia.com \
--cc=palok@marvell.com \
--cc=thomas@monjalon.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).