From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: usages issue with external mempool Date: Thu, 28 Jul 2016 15:55:13 +0530 Message-ID: <20160728102512.GA13403@localhost.localdomain> References: <20160727095128.GA11679@localhost.localdomain> <5799C32C.3050907@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Hemant Agrawal , David Hunt , "dev@dpdk.org" , Thomas Monjalon , "viktorin@rehivetech.com" , Shreyansh Jain To: Olivier MATZ Return-path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0043.outbound.protection.outlook.com [104.47.40.43]) by dpdk.org (Postfix) with ESMTP id 4B23332A5 for ; Thu, 28 Jul 2016 12:25:27 +0200 (CEST) Content-Disposition: inline In-Reply-To: <5799C32C.3050907@6wind.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" On Thu, Jul 28, 2016 at 10:32:44AM +0200, Olivier MATZ wrote: Hi Olivier, > Hi Hemant, Jerin, > > On 07/27/2016 11:51 AM, Jerin Jacob wrote: > > On Tue, Jul 26, 2016 at 10:11:13AM +0000, Hemant Agrawal wrote: > > > > > 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. > > I disagree that changing from one function do_many_stuff(11 args) to several > do_one_stuff(few args) functions is a regression. > > I don't feel that having a new function with 12 args solves anything. > What is the problem of having 20 lines of code for initializing a mbuf pool? > The new API gives more flexibility, and it allow an application to define > its own function if the default one cannot be used. > The problem I have in this scheme is that there is no visibility on converging part of external vs default based pool manager Creation/usage. Can we deprecate the original (11 args) API have ONLY ONE WAY to create/use the mempool irrespective of external or internal ?.So in application perspective it is converged and its matter selecting the handler name. I believe deprecation of (11 args) API is the only that can happen ? Any other thoughts on converging it? for an example, look at cryptodev, selection of SW based virtual or HW based physical device section and usage are identical in APPLICATION perspective. > I think that the name of the functions pretty well defines what they do: > > rte_mempool_create_empty(): create an empty mempool > rte_mempool_set_ops_byname(): set the mempool handler from its name > rte_pktmbuf_pool_init(): initialize the mempool as a packet pool > rte_mempool_populate_default(): populate the pool with objects > rte_mempool_obj_iter(): call a function for each object > I agree.New APIs are great. See above Jerin