From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>,
David Hunt <david.hunt@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"viktorin@rehivetech.com" <viktorin@rehivetech.com>,
Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: usages issue with external mempool
Date: Thu, 28 Jul 2016 15:55:13 +0530 [thread overview]
Message-ID: <20160728102512.GA13403@localhost.localdomain> (raw)
In-Reply-To: <5799C32C.3050907@6wind.com>
On Thu, Jul 28, 2016 at 10:32:44AM +0200, Olivier MATZ wrote:
Hi Olivier,
> Hi Hemant, Jerin,
>
> On 07/27/2016 11:51 AM, Jerin Jacob wrote:
> > On Tue, Jul 26, 2016 at 10:11:13AM +0000, Hemant Agrawal wrote:
>
> >
> > I agree, To me, this is very bad. I have raised this concern earlier
> > also
> >
> > Since applications like OVS goes through "rte_mempool_create" for
> > even packet buffer pool creation. IMO it make senses to extend
> > "rte_mempool_create" to take one more argument to provide external pool
> > handler name(NULL for default). I don't see any valid technical reason
> > to treat external pool handler based mempool creation API different
> > from default handler.
>
> I disagree that changing from one function do_many_stuff(11 args) to several
> do_one_stuff(few args) functions is a regression.
>
> I don't feel that having a new function with 12 args solves anything.
> What is the problem of having 20 lines of code for initializing a mbuf pool?
> The new API gives more flexibility, and it allow an application to define
> its own function if the default one cannot be used.
>
The problem I have in this scheme is that there is no visibility on converging part of
external vs default based pool manager Creation/usage. Can we deprecate the
original (11 args) API have ONLY ONE WAY to create/use the mempool
irrespective of external or internal ?.So in application perspective it is
converged and its matter selecting the handler name.
I believe deprecation of (11 args) API is the only that can happen ?
Any other thoughts on converging it?
for an example,
look at cryptodev, selection of SW based virtual or HW based physical
device section and usage are identical in APPLICATION perspective.
> I think that the name of the functions pretty well defines what they do:
>
> rte_mempool_create_empty(): create an empty mempool
> rte_mempool_set_ops_byname(): set the mempool handler from its name
> rte_pktmbuf_pool_init(): initialize the mempool as a packet pool
> rte_mempool_populate_default(): populate the pool with objects
> rte_mempool_obj_iter(): call a function for each object
>
I agree.New APIs are great. See above
Jerin
next prev parent reply other threads:[~2016-07-28 10:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 10:11 usages issue with external mempool Hemant Agrawal
2016-07-27 9:51 ` Jerin Jacob
2016-07-27 10:00 ` Thomas Monjalon
2016-07-27 13:23 ` Hemant Agrawal
2016-07-27 13:35 ` Thomas Monjalon
2016-07-27 16:52 ` Hemant Agrawal
2016-07-28 7:09 ` Thomas Monjalon
2016-07-28 8:32 ` Olivier MATZ
2016-07-28 10:25 ` Jerin Jacob [this message]
2016-07-29 10:09 ` Hemant Agrawal
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=20160728102512.GA13403@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=olivier.matz@6wind.com \
--cc=shreyansh.jain@nxp.com \
--cc=thomas.monjalon@6wind.com \
--cc=viktorin@rehivetech.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.