[dpdk-dev] [PATCH v3 2/2] ethdev: allow pmd to advertise pool handle

[santosh]

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.