From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: David Hunt <david.hunt@intel.com>,
dev@dpdk.org, "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"viktorin@rehivetech.com" <viktorin@rehivetech.com>,
Shreyansh Jain <shreyansh.jain@nxp.com>
Subject: Re: usages issue with external mempool
Date: Wed, 27 Jul 2016 12:00:34 +0200 [thread overview]
Message-ID: <1626416.VyKLPpZHgH@xps13> (raw)
In-Reply-To: <20160727095128.GA11679@localhost.localdomain>
2016-07-27 15:21, Jerin Jacob:
> On Tue, Jul 26, 2016 at 10:11:13AM +0000, Hemant Agrawal wrote:
> > This is not a user friendly approach to ask for changing 1 API to 6 new APIs. Or, am I missing something?
>
> 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.
>
> Oliver, David
>
> Thoughts ?
>
> If we agree on this then may be I can send the API deprecation notices for
> rte_mempool_create for v16.11
It would have been a lot better to send a patch during the 16.07 cycle
to avoid breaking again the API.
I'm afraid it will even be too late for the deprecation notice.
next prev parent reply other threads:[~2016-07-27 10:00 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 [this message]
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
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=1626416.VyKLPpZHgH@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=olivier.matz@6wind.com \
--cc=shreyansh.jain@nxp.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.