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 B78FC1B2C9 for ; Thu, 18 Jan 2018 14:42:08 +0100 (CET) Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ecASJ-0007jf-Sk; Thu, 18 Jan 2018 14:42:13 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Thu, 18 Jan 2018 14:42:06 +0100 Date: Thu, 18 Jan 2018 14:42:06 +0100 From: Olivier Matz To: Hemant Agrawal Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, santosh.shukla@caviumnetworks.com Message-ID: <20180118134206.3oif7uektnifjwte@platinum> References: <1513333483-4372-1-git-send-email-hemant.agrawal@nxp.com> <1515996674-26338-1-git-send-email-hemant.agrawal@nxp.com> <20180116150134.o3wgrsh4nhh7ptwq@platinum> <7181c81d-869b-32d8-e767-2ac5012ce1a1@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7181c81d-869b-32d8-e767-2ac5012ce1a1@nxp.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 0/5] Dynamic HW Mempool Detection Support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 13:42:08 -0000 Hi Hemant, On Thu, Jan 18, 2018 at 05:17:17PM +0530, Hemant Agrawal wrote: > On 1/16/2018 8:31 PM, Olivier Matz wrote: > > On Mon, Jan 15, 2018 at 11:41:09AM +0530, Hemant Agrawal wrote: > > > W.r.t the multiple discussions in the past about the ability to > > > dynamically detect the HW mempool support. [1],[2] & [3] > > > > > > This patchset helps in removing the current static mempool selection > > > model and provides a flexible model to select the pktmbuf mempool > > > in more dynamic way. > > > > > > 1) This patchset updates the hw mempool on the basis of device probe()), > > > thus avoiding the need to specify the hw mempool in config file and > > > focing different binaries for diffirent config architectures. > > > 2) Selection of mempool ops though --mbuf-pool-ops-name (cmd line arg) > > > which can overridden the scheme(1) > > > 3) A new best mempool ops selection logic. > > > 4) A new wrapper for the pktmbuf_pool_create helper to take mempool ops > > > name as an argument as well. > > > > > > *Limitations and open points* > > > > > > It was suggested to add all APIs in librte_mbuf, currently internal_config > > > is storing the mempool_ops names. So internal_config is exported in this > > > patchset. An alternate would be to keep these APIs in eal only and access > > > them indirectly from librte_mbuf. > > > > Instead of storing the mempool_ops name in internal config, can't it be > > stored inside librte_mbuf? The eal code can call > > rte_mbuf_set_user_mempool_ops(name) while parsing the arguments. > > I doubt that eal can call mbuf APIs. It will be a issue in shared build? You are right. The proper way is maybe to keep the parsing in eal, and at librte_mbuf initialization, query the eal library to get the user pool if any. After that, all will be managed inside librte_mbuf. So the eal lib will only do the argument parsing. This is maybe what you already did in the v3 you just submitted, I'll manage to have a look at it today. Thanks, Olivier