From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 2/6] mempool: add stack (lifo) based external mempool handler Date: Fri, 4 Mar 2016 10:04:57 +0100 Message-ID: <56D94FB9.60509@6wind.com> References: <1453829155-1366-1-git-send-email-david.hunt@intel.com> <1455634095-4183-1-git-send-email-david.hunt@intel.com> <1455634095-4183-3-git-send-email-david.hunt@intel.com> <56C71919.50506@6wind.com> <56D425CC.4020709@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: "Hunt, David" , dev@dpdk.org Return-path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 337912BA6 for ; Fri, 4 Mar 2016 10:05:08 +0100 (CET) In-Reply-To: <56D425CC.4020709@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi David, On 02/29/2016 12:04 PM, Hunt, David wrote: > > On 2/19/2016 1:31 PM, Olivier MATZ wrote: >> Hi David, >> >> On 02/16/2016 03:48 PM, David Hunt wrote: >>> adds a simple stack based mempool handler >>> >>> Signed-off-by: David Hunt >>> --- >>> lib/librte_mempool/Makefile | 2 +- >>> lib/librte_mempool/rte_mempool.c | 4 +- >>> lib/librte_mempool/rte_mempool.h | 1 + >>> lib/librte_mempool/rte_mempool_stack.c | 164 >>> +++++++++++++++++++++++++++++++++ >>> 4 files changed, 169 insertions(+), 2 deletions(-) >>> create mode 100644 lib/librte_mempool/rte_mempool_stack.c >>> >> I don't get what is the purpose of this handler. Is it an example >> or is it something that could be useful for dpdk applications? >> >> If it's an example, we should find a way to put the code outside >> the librte_mempool library, maybe in the test program. I see there >> is also a "custom handler". Do we really need to have both? > They are both example handlers. I agree that we could reduce down to > one, and since the 'custom' handler has autotests, I would suggest we > keep that one. ok > The next question is where it should live. I agree that it's not ideal > to have example code living in the same directory as the mempool > library, but they are an integral part of the library itself. How about > creating a handlers sub-directory? We could then keep all additional and > sample handlers in there, away from the built-in handlers. Also, seeing > as the handler code is intended to be part of the library, I think > moving it out to the examples directory may confuse matters further. I really don't think example code should go in the library. Either it should go in dpdk/examples/ or in dpdk/app/test*. >>From your initial description: "The External Mempool Manager is an extension to the mempool API that allows users to add and use an external mempool manager, which allows external memory subsystems such as external hardware memory management systems and software based memory allocators to be used with DPDK." Can we find a hardware where the external mempool manager is required? This would be the best example ever I think. Regards, Olivier