From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id D30B51B393
 for <dev@dpdk.org>; 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 <olivier.matz@6wind.com>)
 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 <olivier.matz@6wind.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
 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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <hemant.agrawal@nxp.com>
> > > 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.