From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v2 3/5] mbuf: support register mempool Hw ops
	name APIs
Date: Mon, 15 Jan 2018 20:07:50 +0530
Message-ID: <20180115143748.GA27863@jerin>
References: <1513333483-4372-1-git-send-email-hemant.agrawal@nxp.com>
 <1515996674-26338-1-git-send-email-hemant.agrawal@nxp.com>
 <1515996674-26338-4-git-send-email-hemant.agrawal@nxp.com>
 <20180115114127.GA29114@jerin>
 <0eba08d8-543e-49d8-5dd8-e53afa5e5fc8@nxp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org, olivier.matz@6wind.com, santosh.shukla@caviumnetworks.com
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam03on0054.outbound.protection.outlook.com [104.47.41.54])
 by dpdk.org (Postfix) with ESMTP id 7F5D23250
 for <dev@dpdk.org>; Mon, 15 Jan 2018 15:38:56 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <0eba08d8-543e-49d8-5dd8-e53afa5e5fc8@nxp.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

-----Original Message-----
> Date: Mon, 15 Jan 2018 19:54:36 +0530
> From: Hemant Agrawal <hemant.agrawal@nxp.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: dev@dpdk.org, olivier.matz@6wind.com, santosh.shukla@caviumnetworks.com
> Subject: Re: [PATCH v2 3/5] mbuf: support register mempool Hw ops name APIs
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
>  Thunderbird/45.8.0
> 
> On 1/15/2018 5:11 PM, Jerin Jacob wrote:
> > > 
> > > +int
> > > +rte_mbuf_register_platform_mempool_ops(const char *ops_name)
> > > +{
> > 
> > Should we also check the following?
> > 
> > if (internal_config.plat_mbuf_pool_ops_name != NULL &&
> > strncmp(internal_config.plat_mbuf_pool_ops_name, ops_name, ..) == 0)
> > 	return 0;
> > 
> > i.e avoid returning error if the same the driver but another
> > instance(different ethdev port) updates the same ops_name value.
> > 
> 
> No, there shall be only one default platform hw pool name.
> Any ethdev driven (may be weight based) replacement shall be dealt
> separately.

OK. Who calls the rte_mbuf_register_platform_mempool_ops() and when?
mempool ops registration is using gcc construction scheme so it will 
be called all the time. I thought, ethdev drivers will call this API on
pci or any other bus probe() and if its in probe() then 
rte_mbuf_register_platform_mempool_ops() will be called multiple time.

What is your thought on this API usage?

>