From: Olivier Matz <olivier.matz@6wind.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>, dev@dpdk.org
Cc: jerin.jacob@caviumnetworks.com, david.hunt@intel.com
Subject: Re: [dpdk-dev] [RFC 0/7] changing mbuf pool handler
Date: Mon, 3 Oct 2016 17:49:44 +0200 [thread overview]
Message-ID: <dc89a863-3f9e-c0e9-a851-04de2f6e08fe@6wind.com> (raw)
In-Reply-To: <d11f3842-d715-3afc-9d5d-9e02f2767c2d@nxp.com>
Hi Hemant,
Thank you for your feedback.
On 09/22/2016 01:52 PM, Hemant Agrawal wrote:
> Hi Olivier
>
> On 9/19/2016 7:12 PM, Olivier Matz wrote:
>> Hello,
>>
>> Following discussion from [1] ("usages issue with external mempool").
>>
>> This is a tentative to make the mempool_ops feature introduced
>> by David Hunt [2] more widely used by applications.
>>
>> It applies on top of a minor fix in mbuf lib [3].
>>
>> To sumarize the needs (please comment if I did not got it properly):
>>
>> - new hw-assisted mempool handlers will soon be introduced
>> - to make use of it, the new mempool API [4] (rte_mempool_create_empty,
>> rte_mempool_populate, ...) has to be used
>> - the legacy mempool API (rte_mempool_create) does not allow to change
>> the mempool ops. The default is "ring_<s|m>p_<s|m>c" depending on
>> flags.
>> - the mbuf helper (rte_pktmbuf_pool_create) does not allow to change
>> them either, and the default is RTE_MBUF_DEFAULT_MEMPOOL_OPS
>> ("ring_mp_mc")
>> - today, most (if not all) applications and examples use either
>> rte_pktmbuf_pool_create or rte_mempool_create to create the mbuf
>> pool, making it difficult to take advantage of this feature with
>> existing apps.
>>
>> My initial idea was to deprecate both rte_pktmbuf_pool_create() and
>> rte_mempool_create(), forcing the applications to use the new API, which
>> is more flexible. But after digging a bit, it appeared that
>> rte_mempool_create() is widely used, and not only for mbufs. Deprecating
>> it would have a big impact on applications, and replacing it with the
>> new API would be overkill in many use-cases.
>
> I agree with the proposal.
>
>>
>> So I finally tried the following approach (inspired from a suggestion
>> Jerin [5]):
>>
>> - add a new mempool_ops parameter to rte_pktmbuf_pool_create(). This
>> unfortunatelly breaks the API, but I implemented an ABI compat layer.
>> If the patch is accepted, we could discuss how to announce/schedule
>> the API change.
>> - update the applications and documentation to prefer
>> rte_pktmbuf_pool_create() as much as possible
>> - update most used examples (testpmd, l2fwd, l3fwd) to add a new command
>> line argument to select the mempool handler
>>
>> I hope the external applications would then switch to
>> rte_pktmbuf_pool_create(), since it supports most of the use-cases (even
>> priv_size != 0, since we can call rte_mempool_obj_iter() after) .
>>
>
> I will still prefer if you can add the "rte_mempool_obj_cb_t *obj_cb,
> void *obj_cb_arg" into "rte_pktmbuf_pool_create". This single
> consolidated wrapper will almost make it certain that applications will
> not try to use rte_mempool_create for packet buffers.
The patch changes the example applications. I'm not sure I understand
why adding these arguments would force application to not use
rte_mempool_create() for packet buffers. Do you have a application in mind?
For the mempool_ops parameter, we must pass it at init because we need
to know the mempool handler before populating the pool. For object
initialization, it can be done after, so I thought it was better to
reduce the number of arguments to avoid to fall in the mempool_create()
syndrom :)
Any other opinions?
Regards,
Olivier
next prev parent reply other threads:[~2016-10-03 15:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 13:42 Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 1/7] mbuf: set the handler at mbuf pool creation Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 2/7] mbuf: use helper to create the pool Olivier Matz
2017-01-16 15:30 ` Santosh Shukla
2017-01-31 10:31 ` Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 3/7] testpmd: new parameter to set mbuf pool ops Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 4/7] l3fwd: rework long options parsing Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 5/7] l3fwd: new parameter to set mbuf pool ops Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 6/7] l2fwd: rework long options parsing Olivier Matz
2016-09-19 13:42 ` [dpdk-dev] [RFC 7/7] l2fwd: new parameter to set mbuf pool ops Olivier Matz
2016-09-22 11:52 ` [dpdk-dev] [RFC 0/7] changing mbuf pool handler Hemant Agrawal
2016-10-03 15:49 ` Olivier Matz [this message]
2016-10-05 9:41 ` Hunt, David
2016-10-05 11:49 ` Hemant Agrawal
2016-10-05 13:15 ` Hunt, David
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=dc89a863-3f9e-c0e9-a851-04de2f6e08fe@6wind.com \
--to=olivier.matz@6wind.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=jerin.jacob@caviumnetworks.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 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).