On Mon, Mar 26, 2018 at 05:12:55PM +0100, Andrew Rybchenko wrote:
> From: "Artem V. Andreev" <artem.andr...@oktetlabs.ru>
>
> Primarily, it is intended as a way for the mempool driver to provide
> additional information on how it lays up objects inside the mempool.
>
> Signed-off-by: Artem V. Andreev <artem.andr...@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <arybche...@solarflare.com>
I think it's a good idea to have a way to query mempool features
or parameters. The approach chosen in this patch looks similar
to what we have with ethdev devinfo, right?
[...]
> /**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Additional information about the mempool
> + */
> +struct rte_mempool_info;
> +
[...]
> +/* wrapper to get additional mempool info */
> +int
> +rte_mempool_ops_get_info(const struct rte_mempool *mp,
> + struct rte_mempool_info *info)
> +{
> + struct rte_mempool_ops *ops;
> +
> + ops = rte_mempool_get_ops(mp->ops_index);
> +
> + RTE_FUNC_PTR_OR_ERR_RET(ops->get_info, -ENOTSUP);
> + return ops->get_info(mp, info);
> +}
Thinking in terms of ABI compatibility, it looks that each time we will
add or remove a field, it will break the ABI because the info structure
will change.
Well, it's maybe nitpicking, because most of the time adding a field in
info structure goes with adding a field in the mempool struct, which
will anyway break the ABI.
Another approach is to have a function
rte_mempool_info_contig_block_size(mp) whose ABI can be more easily
wrapped with VERSION_SYMBOL().
On my side I'm fine with your current approach, especially given how few
usages of VERSION_SYMBOL() we can find in DPDK. But in case you feel
it's better to have a function...
