[dpdk-dev] [PATCH v3 2/2] ethdev: allow pmd to advertise pool handle
Olivier MATZ
olivier.matz at 6wind.com
Mon Sep 11 15:00:38 CEST 2017
On Mon, Sep 11, 2017 at 06:10:36PM +0530, santosh wrote:
> 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?
It's ok for me.
More information about the dev
mailing list