Re: [dpdk-dev] [PATCH v2 0/5] Dynamic HW Mempool Detection Support

[Hemant Agrawal <hemant.agrawal@nxp.com>]

On 1/16/2018 8:31 PM, Olivier Matz wrote:
> On Mon, Jan 15, 2018 at 11:41:09AM +0530, Hemant Agrawal wrote:
>> W.r.t the multiple discussions in the past about the ability to
>> dynamically detect the HW mempool support. [1],[2] & [3]
>>
>> This patchset helps in removing the current static mempool selection
>> model and provides a flexible model to select the pktmbuf mempool
>> in more dynamic way.
>>
>> 1) This patchset updates the hw mempool on the basis of device probe()),
>>    thus avoiding the need to specify the hw mempool in config file and
>>    focing different binaries for diffirent config architectures.
>> 2) Selection of mempool ops though --mbuf-pool-ops-name (cmd line arg)
>>    which can overridden the scheme(1)
>> 3) A new best mempool ops selection logic.
>> 4) A new wrapper for the pktmbuf_pool_create helper to take mempool ops
>>    name as an argument as well.
>>
>> *Limitations and open points*
>>
>> It was suggested to add all APIs in librte_mbuf, currently internal_config
>> is storing the mempool_ops names. So internal_config is exported in this
>> patchset. An alternate would be to keep these APIs in eal only and access
>> them indirectly from librte_mbuf.
>
> Instead of storing the mempool_ops name in internal config, can't it be
> stored inside librte_mbuf? The eal code can call
> rte_mbuf_set_user_mempool_ops(name) while parsing the arguments.

I doubt that eal can call mbuf APIs. It will be a issue in shared build?

>
> It has to be done carefully so that it works with secondary processes.
>
>
>> Moreover, this logic can be further extended with addition for following
>> patch, which is still under discussion:
>>
>> The ethdev PMD capability exposed through existing
>> rte_eth_dev_pool_ops_supported() to select the update the mempool ops with
>> some "weight" based algorithm like:
>> http://dpdk.org/dev/patchwork/patch/32245/
>>
>> -----
>> [1]Multiple Pktmbuf mempool support
>> http://dpdk.org/ml/archives/dev/2017-September/076531.html
>> [2]Allow application set mempool handle
>> http://dpdk.org/ml/archives/dev/2017-June/067022.html
>> Other discussions
>> [3] http://dpdk.org/ml/archives/dev/2017-December/084775.html
>> ------
>> Changes in v2:
>> 1. Changed the active mempool to platform mempool
>> 2. Moved all the relavant APIs to librte_mbuf
>> 3. Added pktmbuf_create_pool_specific wrapper in this patch series.
>>
>> Hemant Agrawal (5):
>>   eal: prefix mbuf pool ops name with user defined
>>   eal: add platform mempool ops name in internal config
>>   mbuf: support register mempool Hw ops name APIs
>>   mbuf: pktmbuf pool create helper for specific mempool ops
>>   mbuf: add user command line config mempools ops API
>>
>>  doc/guides/rel_notes/deprecation.rst       |  7 +++
>>  lib/librte_eal/bsdapp/eal/eal.c            |  4 +-
>>  lib/librte_eal/common/eal_common_options.c |  3 +-
>>  lib/librte_eal/common/eal_internal_cfg.h   |  5 ++-
>>  lib/librte_eal/linuxapp/eal/eal.c          |  4 +-
>>  lib/librte_eal/rte_eal_version.map         |  1 +
>>  lib/librte_mbuf/Makefile                   |  1 +
>>  lib/librte_mbuf/rte_mbuf.c                 | 67 ++++++++++++++++++++++++---
>>  lib/librte_mbuf/rte_mbuf.h                 | 72 ++++++++++++++++++++++++++++++
>
> I think the code to manage the user/platform mempool ops could
> go in a separate file. What about rte_mbuf_pool_ops.[ch] ?
>

Good suggestion.