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 D30B51B393 for ; Fri, 22 Dec 2017 16:00:13 +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.84_2) (envelope-from ) id 1eSOu4-0006gs-3j; Fri, 22 Dec 2017 16:06:29 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Fri, 22 Dec 2017 15:59:58 +0100 Date: Fri, 22 Dec 2017 15:59:58 +0100 From: Olivier MATZ To: Hemant Agrawal Cc: Jerin Jacob , santosh.shukla@caviumnetworks.com, dev@dpdk.org Message-ID: <20171222145957.tc56hzyzbxj65rg5@platinum> References: <1499170968-23016-1-git-send-email-hemant.agrawal@nxp.com> <1513333483-4372-1-git-send-email-hemant.agrawal@nxp.com> <1513333483-4372-2-git-send-email-hemant.agrawal@nxp.com> <20171218085507.GA20578@jerin> <85485fb0-f602-78af-c40a-7bfb4bda561e@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85485fb0-f602-78af-c40a-7bfb4bda561e@nxp.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW active pool 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: Fri, 22 Dec 2017 15:00:14 -0000 On Mon, Dec 18, 2017 at 03:06:21PM +0530, Hemant Agrawal wrote: > On 12/18/2017 2:25 PM, Jerin Jacob wrote: > > -----Original Message----- > > > Date: Fri, 15 Dec 2017 15:54:42 +0530 > > > From: Hemant Agrawal > > > To: olivier.matz@6wind.com, santosh.shukla@caviumnetworks.com > > > CC: dev@dpdk.org > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW > > > active pool > > > X-Mailer: git-send-email 2.7.4 > > > > > > With this patch the specific HW mempool are no longer required to be > > > specified in the config file at compile. A default active hw mempool > > > can be detected dynamically and published to default mempools ops > > > config at run time. Only one type of HW mempool can be active default. > > > > For me, it looks very reasonable approach as it caters the basic use > > case without any change in the application nor the additional(--mbuf-pool-ops-name) > > EAL command line scheme to select different mempool ops. > > Though, this option will not enough cater all the use case. I think, we can have > > three options and the following order of precedence to select the mempool ops > > > > 1) This patch(update active mempool based on the device probe()) > > 2) Selection of mempool ops though --mbuf-pool-ops-name= EAL commandline argument. > > Which can overridden the scheme(1) > > 3) More sophisticated mempool section based on > > a) The ethdev PMD capability exposed through existing rte_eth_dev_pool_ops_supported() > > b) Add mempool ops option in rte_pktmbuf_pool_create() > > http://dpdk.org/ml/archives/dev/2017-December/083985.html > > c) Use (a) and (b) to select the update the mempool ops with > > some "weight" based algorithm like > > http://dpdk.org/dev/patchwork/patch/32245/ > > > > Yes! We need more options to fine tune control over the mempool uses, > specially when dealing with HW mempools. > > Once the above mentioned mechanisms will be in place, it will be much easier > and flexible. I'm inline with this description. It would be great if the same binary can work on different platforms without configuration. I just feel it's a bit messy to have: - rte_eal_mbuf_default_mempool_ops() in eal API return user-selected ops if any, or compile-time default - rte_pktmbuf_active_mempool_ops() in mbuf API return platform ops except if a selected user ops != compile default Thomas suggested somewhere (but I don't remember in which thread) to have rte_eal_mbuf_default_mempool_ops() in mbuf code, and I think he was right. I think the whole mbuf pool ops selection mechanism should be at the same place. I could be in a specific file of librte_mbuf. The API could be: - get compile time default ops - get/set platform ops (NULL if none) - get/set user ops (NULL if none) - get preferred ops from currently configured PMD - get best ops: return user, or pmd-prefered, or platform, or default. rte_pktmbuf_pool_create() will use "get best ops" if no ops (NULL) is passed as argument.