From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hemant Agrawal Subject: Re: [PATCH v2 0/5] Dynamic HW Mempool Detection Support Date: Thu, 18 Jan 2018 17:17:17 +0530 Message-ID: <7181c81d-869b-32d8-e767-2ac5012ce1a1@nxp.com> References: <1513333483-4372-1-git-send-email-hemant.agrawal@nxp.com> <1515996674-26338-1-git-send-email-hemant.agrawal@nxp.com> <20180116150134.o3wgrsh4nhh7ptwq@platinum> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , To: Olivier Matz Return-path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0076.outbound.protection.outlook.com [104.47.32.76]) by dpdk.org (Postfix) with ESMTP id BB1851B298 for ; Thu, 18 Jan 2018 12:47:24 +0100 (CET) In-Reply-To: <20180116150134.o3wgrsh4nhh7ptwq@platinum> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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? > > It has to be done carefully so that it works with secondary processes. > > >> Moreover, this logic can be further extended with addition for following >> patch, which is still under discussion: >> >> The ethdev PMD capability exposed through existing >> rte_eth_dev_pool_ops_supported() to select the update the mempool ops with >> some "weight" based algorithm like: >> http://dpdk.org/dev/patchwork/patch/32245/ >> >> ----- >> [1]Multiple Pktmbuf mempool support >> http://dpdk.org/ml/archives/dev/2017-September/076531.html >> [2]Allow application set mempool handle >> http://dpdk.org/ml/archives/dev/2017-June/067022.html >> Other discussions >> [3] http://dpdk.org/ml/archives/dev/2017-December/084775.html >> ------ >> Changes in v2: >> 1. Changed the active mempool to platform mempool >> 2. Moved all the relavant APIs to librte_mbuf >> 3. Added pktmbuf_create_pool_specific wrapper in this patch series. >> >> Hemant Agrawal (5): >> eal: prefix mbuf pool ops name with user defined >> eal: add platform mempool ops name in internal config >> mbuf: support register mempool Hw ops name APIs >> mbuf: pktmbuf pool create helper for specific mempool ops >> mbuf: add user command line config mempools ops API >> >> doc/guides/rel_notes/deprecation.rst | 7 +++ >> lib/librte_eal/bsdapp/eal/eal.c | 4 +- >> lib/librte_eal/common/eal_common_options.c | 3 +- >> lib/librte_eal/common/eal_internal_cfg.h | 5 ++- >> lib/librte_eal/linuxapp/eal/eal.c | 4 +- >> lib/librte_eal/rte_eal_version.map | 1 + >> lib/librte_mbuf/Makefile | 1 + >> lib/librte_mbuf/rte_mbuf.c | 67 ++++++++++++++++++++++++--- >> lib/librte_mbuf/rte_mbuf.h | 72 ++++++++++++++++++++++++++++++ > > I think the code to manage the user/platform mempool ops could > go in a separate file. What about rte_mbuf_pool_ops.[ch] ? > Good suggestion.