From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 3B2938D28 for ; Tue, 21 Jun 2016 11:44:47 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bFIGv-0000nP-0w; Tue, 21 Jun 2016 11:47:05 +0200 To: "Ananyev, Konstantin" , Jerin Jacob 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> <3416153.NDoMD8TpjF@xps13> <2601191342CEEE43887BDE71AB97725836B73750@irsmsx105.ger.corp.intel.com> <20160620142205.GA4118@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B73B9B@irsmsx105.ger.corp.intel.com> <20160621033459.GA4903@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B73FE3@irsmsx105.ger.corp.intel.com> Cc: Thomas Monjalon , "dev@dpdk.org" , "Hunt, David" , "viktorin@rehivetech.com" , "shreyansh.jain@nxp.com" From: Olivier Matz Message-ID: <57690C83.6060404@6wind.com> Date: Tue, 21 Jun 2016 11:44:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725836B73FE3@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 1/2] mempool: add stack (lifo) mempool handler X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:44:47 -0000 Hi, On 06/21/2016 11:28 AM, Ananyev, Konstantin wrote: >>>> I was proposing only to move only the new >>>> handler(lib/librte_mempool/rte_mempool_stack.c). Not any library or any >>>> other common code. >>>> >>>> Just like DPDK crypto device, Even if it is software implementation its >>>> better to move in driver/crypto instead of lib/librte_cryptodev >>>> >>>> "lib/librte_mempool/arch/" is not correct place as it is platform specific >>>> not architecture specific and HW mempool device may be PCIe or platform >>>> device. >>> >>> Ok, but why rte_mempool_stack.c has to be moved? >> >> Just thought of having all the mempool handlers at one place. >> We can't move all HW mempool handlers at lib/librte_mempool/ > > Yep, but from your previous mail I thought we might have specific ones > for specific devices, no? > If so, why to put them in one place, why just not in: > Drivers/xxx_dev/xxx_mempool.[h,c] > ? > And keep generic ones in lib/librte_mempool > ? I think all drivers (generic or not) should be at the same place for consistency. I'm not sure having them lib/librte_mempool is really a problem today, but once hardware-dependent handler are pushed, we may move all of them in drivers/mempool because I think we should avoid to have hw-specific code in lib/. I don't think it will cause ABI/API breakage since the user always talk to the generic mempool API. Regards Olivier