From mboxrd@z Thu Jan  1 00:00:00 1970
From: santosh <santosh.shukla@caviumnetworks.com>
Subject: Re: [PATCH v3 2/2] ethdev: allow pmd to advertise pool
	handle
Date: Mon, 11 Sep 2017 18:10:36 +0530
Message-ID: <d3eaf611-47ad-10be-5df7-587cf1cdf106@caviumnetworks.com>
References: <20170720070613.18211-2-santosh.shukla@caviumnetworks.com>
 <20170815080717.9413-1-santosh.shukla@caviumnetworks.com>
 <20170815080717.9413-3-santosh.shukla@caviumnetworks.com>
 <20170904121113.jdilonuhw77c4vx7@neon>
 <5fc11fd6-3741-ae25-d5e1-3bc8a643661c@caviumnetworks.com>
 <0df45c69-6e54-5e6a-354e-e5c2ba6d578e@nxp.com>
 <08aaa47a-b2e2-4b02-a9c3-6e3638503f1f@caviumnetworks.com>
 <4cfc26cb-18bf-76b3-af3c-5dacd86cd52e@caviumnetworks.com>
 <8e66eab5-51a5-af0c-8b0c-3879c516364c@nxp.com>
 <20170911093333.7tt3zdzdam3tshra@neon>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, thomas@monjalon.net, jerin.jacob@caviumnetworks.com
To: Olivier MATZ <olivier.matz@6wind.com>,
 Hemant Agrawal <hemant.agrawal@nxp.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM01-BY2-obe.outbound.protection.outlook.com
 (mail-by2nam01on0040.outbound.protection.outlook.com [104.47.34.40])
 by dpdk.org (Postfix) with ESMTP id 1A682592B
 for <dev@dpdk.org>; Mon, 11 Sep 2017 14:40:54 +0200 (CEST)
In-Reply-To: <20170911093333.7tt3zdzdam3tshra@neon>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Olivier,


On Monday 11 September 2017 03:03 PM, Olivier MATZ wrote:
> On Thu, Sep 07, 2017 at 04:38:39PM +0530, Hemant Agrawal wrote:
>> On 9/7/2017 3:41 PM, santosh wrote:
>>> Sorry for the font, resending proposed API:
>>>
>>> /**
>>>  * Get list of supported pools for a port
>>>  * @param port_id [in]
>>>  *   Pointer to port identifier of the device.
>>>  * @param pools [out]
>>>  * Pointer to the list of supported pools for that port.
>>>  * Returns with array of pool ops name handler of size
>>>  * RTE_MEMPOOL_OPS_NAMESIZE.
>>>  * @return
>>>  * >=0: Success; PMD has updated supported pool list.
>>>  * <0: Failure;
>>>  */
>>>
>>> int rte_eth_dev_pools_ops_supported(uint8_t port_id, char **pools)
>>>
>>> Hemant, Olivier: Does above api make sense? Pl. confirm. Thanks.
>>>
>> looks ok to me.
> I think that returning a list is harder to use in an application, instead of an
> api that just returns an int (priority):
>
> int rte_eth_dev_pool_ops_supported(uint8_t port_id, const char *pool)
>
> The possible returned values are:
>   ENOTSUP: mempool ops not supported
>   < 0: any other error
>   0: best mempool ops choice for this pmd
>   1: this mempool ops are supported
>
> Let's take an example. Our application wants to select ops that
> will match all pmds. The pseudo code would be like this:
>
> best_score = -1
> best_ops = NULL
> for ops in mempool_ops:
>   score = 0
>   for p in ports:
>     ret = rte_eth_dev_pools_ops_supported(p, ops.name)
>     if ret < 0:
>       score = -1
>       break
>     score += ret
>   if score == -1:
>     continue
>   if best_score == -1 || score < best_score:
>     best_score = score
>     best_ops = ops
> if best_score == -1:
>   print "no matching mempool ops"
> else:
>   print "selected ops: %s", best_ops.name
>
>
> You can do the exercise with the API you are proposing, but I think
> it would be harder.
>
> Olivier

Proposed model looks okay and I'll implement _pool_ops_supported() api.
But I cant promise the testpmd related changes with this series,
Since rc1 is closing so let the api go in -rc1 release and testpmd changes will
follow then. is it ok with you?

Thanks.