From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v3 1/2] mempool: add stack (lifo) mempool
	handler
Date: Mon, 20 Jun 2016 15:54:20 +0200
Message-ID: <3416153.NDoMD8TpjF@xps13>
References: <1463669335-30378-1-git-send-email-david.hunt@intel.com>
 <1466428091-115821-2-git-send-email-david.hunt@intel.com>
 <20160620132506.GA3301@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, David Hunt <david.hunt@intel.com>, olivier.matz@6wind.com,
 viktorin@rehivetech.com, shreyansh.jain@nxp.com
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
 by dpdk.org (Postfix) with ESMTP id 8A4D86CC3
 for <dev@dpdk.org>; Mon, 20 Jun 2016 15:54:27 +0200 (CEST)
Received: by mail-wm0-f52.google.com with SMTP id v199so70330237wmv.0
 for <dev@dpdk.org>; Mon, 20 Jun 2016 06:54:27 -0700 (PDT)
In-Reply-To: <20160620132506.GA3301@localhost.localdomain>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-06-20 18:55, Jerin Jacob:
> On Mon, Jun 20, 2016 at 02:08:10PM +0100, David Hunt wrote:
> > This is a mempool handler that is useful for pipelining apps, where
> > the mempool cache doesn't really work - example, where we have one
> > core doing rx (and alloc), and another core doing Tx (and return). In
> > such a case, the mempool ring simply cycles through all the mbufs,
> > resulting in a LLC miss on every mbuf allocated when the number of
> > mbufs is large. A stack recycles buffers more effectively in this
> > case.
> > 
> > Signed-off-by: David Hunt <david.hunt@intel.com>
> > ---
> >  lib/librte_mempool/Makefile            |   1 +
> >  lib/librte_mempool/rte_mempool_stack.c | 145 +++++++++++++++++++++++++++++++++
> 
> How about moving new mempool handlers to drivers/mempool? (or similar).
> In future, adding HW specific handlers in lib/librte_mempool/ may be bad idea.

You're probably right.
However we need to check and understand what a HW mempool handler will be.
I imagine the first of them will have to move handlers in drivers/
Jerin, are you volunteer?