DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Santosh Shukla <santosh.shukla@caviumnetworks.com>
Cc: <dev@dpdk.org>, <jerin.jacob@caviumnetworks.com>,
	<hemant.agrawal@nxp.com>, <david.hunt@intel.com>
Subject: Re: [dpdk-dev] [RFC 2/7] mbuf: use helper to create the pool
Date: Tue, 31 Jan 2017 11:31:58 +0100	[thread overview]
Message-ID: <20170131113158.25f74dc3@platinum> (raw)
In-Reply-To: <20170116153022.GA8179@santosh-Latitude-E5530-non-vPro>

Hi Santosh,

On Mon, 16 Jan 2017 21:00:37 +0530, Santosh Shukla
<santosh.shukla@caviumnetworks.com> wrote:
> Hi Olivier,
> 
> 
> On Mon, Sep 19, 2016 at 03:42:42PM +0200, Olivier Matz wrote:
> > When possible, replace the uses of rte_mempool_create() with
> > the helper provided in librte_mbuf: rte_pktmbuf_pool_create().
> > 
> > This is the preferred way to create a mbuf pool.
> > 
> > By the way, akso update the documentation.
> >  
> 
> I am working on ext-mempool pmd driver for cvm soc.
> So interested in this thread.
> 
> Wondering why this thread not followed up, is it
> because we don't want to deprecate rte_mempool_create()?
> Or if we want to then in which release you are targeting.

It seems that the RFC patchset was not the proper way to fix the issue.
On the other hand, this particular patch should be integrated, as
highlighted by Hemant too. Thanks for reminding it.

> Beside that some high level comment -
> - Your changeset missing mempool test application i.e..
> test_mempool.c/ test_mempool_perf.c; Do you plan to accomodate them?

As answered in the other thread, I think there is nothing to change
in test_mempool*.c, since this patch is just about mbuf pools.


> - ext-mempool does not necessarily need MBUF_CACHE_SIZE. Let HW-mngr
> to directly handover buffer to application; Rather caching same
> buffer per core way. It will save some cycles. What do you think?

It's still possible to set the cache size to 0. In that case, it will
directly call rte_mempool_ops_dequeue_bulk(). But, given the function
call to ops->dequeue() and the few tests, it is probably faster to use
the cache, even with a fast hw allocation.


> - I figured out that ext-mempool API not mapping well on cvm hw; For
> few reason:
>   Lets say application calls:
>   rte_pktmbuf_pool_create()
>    --> rte_mempool_create_empty()
>    --> rte_mempool_ops_byname()
>    --> rte_mempool_populate_default()  
>          -->> rte_mempool_ops_alloc()  
>                   --> ext-mempool-specific-pool-create handle  
> [...]

I'm answering in the other thread.

Thanks,
Olivier

  reply	other threads:[~2017-01-31 10:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19 13:42 [dpdk-dev] [RFC 0/7] changing mbuf pool handler 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 [this message]
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
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=20170131113158.25f74dc3@platinum \
    --to=olivier.matz@6wind.com \
    --cc=david.hunt@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=santosh.shukla@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).