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. 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] ?
