From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 92E541B208 for ; Tue, 10 Oct 2017 16:15:40 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 257C920C94; Tue, 10 Oct 2017 10:15:40 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 10 Oct 2017 10:15:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ViZjpZwc8gXooDB NV4hADYcTpZyM1W7ODJoBD/L9keM=; b=Jf4i5TCCpO+guzBdDgOuJqTvB/dQotp +PPjisj7VVqpJU4snssvFEErT7DCQQpwQiViD4BexY9ZAu3qCcv6xN79emCnwMgf BXVw3nliV8Lhwx0prKwlsTNKs9B8986j+Y3D4f5+d6FySyHfxvvcXQVCAMsr6kyE IZKXthsJTEOo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ViZjpZwc8gXooDBNV4hADYcTpZyM1W7ODJoBD/L9keM=; b=nzfVFpcl vlKv6JmNikEg3BvSb50nBxGVif0Tq86EHJ/nhIMaLo6qA4i9wvWc0D8MPW4OSazC 0e05VRtS4OUOe5g3/b9Uhuy8RN5wAuUTSuNI2gYlGr2lOEtkNTWhFQ9oudNcG+5g s7FDRyZMl1a0/ltC3bPWTo4Axdaujz2gIaDFl5q1ZW6DgTkuKRiDNtj7Ge+n5JuD QgdgnuvmTQwIAJ+nxADOqLk+VPhdNR7C6sW1nHEvR0k6yE//bb49fDLulypbJ5IQ RjombkXNEB9/jx04eYwLw3XnL9RY41x8XtYAjYCExB3OOVnZ0eG06KUBZCQKaQg0 uRvd6tG9Tdp0KQ== X-ME-Sender: X-Sasl-enc: wP6R6UHM4cKqJBmPc1GdSpHz+EnqMerB6mCjGRlpK+Gh 1507644939 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CA8AE2418B; Tue, 10 Oct 2017 10:15:39 -0400 (EDT) From: Thomas Monjalon To: Olivier MATZ , Hemant Agrawal Cc: dev@dpdk.org, santosh.shukla@caviumnetworks.com, jerin.jacob@caviumnetworks.com Date: Tue, 10 Oct 2017 16:15:38 +0200 Message-ID: <2060170.kPZRRlM5QW@xps> In-Reply-To: <20170925102439.jpk4qynni6hmonif@platinum> References: <1499170968-23016-1-git-send-email-hemant.agrawal@nxp.com> <08774e28-430e-4680-587a-909a5f44c5d6@nxp.com> <20170925102439.jpk4qynni6hmonif@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 0/2] Multiple Pktmbuf mempool 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: Tue, 10 Oct 2017 14:15:40 -0000 25/09/2017 12:24, Olivier MATZ: > Hi Hemant, > > On Fri, Sep 22, 2017 at 12:43:36PM +0530, Hemant Agrawal wrote: > > On 7/4/2017 5:52 PM, Hemant Agrawal wrote: > > > This patch is in addition to the patch series[1] submitted by > > > Santosh to allow application to set mempool handle. > > > > > > The existing pktmbuf pool create api only support the internal use > > > of "CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS", which assumes that the HW > > > can only support one type of mempool for packet mbuf. > > > > > > There are multiple additional requirements. > > > > > > 1. The platform independent image detects the underlying bus, > > > based on the bus and resource detected, it will dynamically select > > > the default mempool. This need not to have the application knowlege. > > > e.g. DPAA2 and DPAA are two different NXP platforms, based on the > > > underlying platform the default ops for mbuf can be dpaa or dpaa2. > > > Application should work seemlessly whether it is running on dpaa or dpaa2. > > > > > > 2.Platform support more than one type of mempool for pktmbuf, > > > depend on the availability of resource, the driver can decide one > > > of the mempool for the current packet mbuf request. > > > > > > 3. In case of where application is providing the mempool, as proposed > > > in [1], the check preference logic will be bypassed and application > > > config will take priority. > > > > > > [1]Allow application set mempool handle > > > http://dpdk.org/ml/archives/dev/2017-June/067022.html > > > > > > Hemant Agrawal (2): > > > mempool: check the support for the given mempool > > > mbuf: add support for preferred mempool list > > > > > > config/common_base | 2 ++ > > > lib/librte_mbuf/rte_mbuf.c | 28 +++++++++++++++++++++++----- > > > lib/librte_mempool/rte_mempool.h | 24 ++++++++++++++++++++++++ > > > lib/librte_mempool/rte_mempool_ops.c | 32 ++++++++++++++++++++++++++++++++ > > > 4 files changed, 81 insertions(+), 5 deletions(-) > > > > > > > Hi Olivier, > > Any opinion on this patchset? > > Sorry for the lack of feedback, for some reason I missed the initial > mails. > > I don't quite like the idea of having hardcoded config: > CONFIG_RTE_MBUF_BACKUP_MEMPOOL_OPS_1="" > CONFIG_RTE_MBUF_BACKUP_MEMPOOL_OPS_2="" > > Also, I'm a bit reserved about rte_mempool_ops_check_support(): it can > return "supported" but the creation of the pool can still fail later due > to the creation parameters (element count/size, mempool flags, ...). > > The ordering preference of these mempool ops may also depend on the > configuration (enabled ports for instance) or user choices. > > Let me propose you another approach to (I hope) solve your issue, based > on Santosh's patches [1]. > > We can introduce a new helper that could be used by applications to > dynamically select the best mempool ops. It could be something similar > to the pseudo-code I've written in [3]. > > // return an array pool ops name, ordered by preference > pool_ops = get_ordered_pool_ops_list() > > Then try to create the first pool, if it fails, try the next, until > it is succesful. > > That said, it is difficult to take the good decision inside > rte_pktmbuf_pool_create() because we don't have all the information. > Sergio and Jerin suggested to introduce a new argument ops_name to > rte_pktmbuf_pool_create() [2]. From what I remember, this is also > something you were in favor of, right? > > In that case, we can move the difficult task of choosing the > right mempool inside the application. > > Comments? I guess this discussion is obsolete since Santosh commit? http://dpdk.org/commit/a103a97e