Hi Sergio,
On Monday 04 September 2017 03:11 PM, Sergio Gonzalez Monroy wrote: > On 15/08/2017 09:07, Santosh Shukla wrote: >> v3: >> - Rebased on top of v17.11-rc0 >> - Updated version.map entry to v17.11. >> >> v2: >> >> DPDK has support for hw and sw mempool. Those mempool >> can work optimal for specific PMD's. >> Example: >> sw ring based PMD for Intel NICs. >> HW mempool manager dpaa2 for dpaa2 PMD. >> HW mempool manager fpa for octeontx PMD. >> >> There could be a use-case where different vendor NIC's used >> on the same platform and User like to configure mempool in such a way that >> each of those NIC's should use their preferred mempool(For performance >> reasons). >> >> Current mempool infrastrucure don't support such use-case. >> >> This patchset tries to address that problem in 2 steps: >> >> 0) Allowing user to dynamically configure mempool handle by >> passing pool handle as eal arg to `--mbuf-pool-ops=<pool-handle>`. >> >> 1) Allowing PMD's to advertise their preferred pool to an application. >> From an application point of view: >> - The application must ask PMD about their preferred pool. >> - PMD to respond back with preferred pool otherwise >> CONFIG_RTE_MEMPOOL_DEFAULT_OPS will be used for that PMD. >> >> * Application programming sequencing would be >> char pref_mempool[RTE_MEMPOOL_OPS_NAMESIZE]; >> rte_eth_dev_get_preferred_pool_ops(ethdev_port_id, pref_mempool /* out >> */); >> rte_mempool_create_empty(); >> rte_mempool_set_ops_byname( , pref_memppol, ); >> rte_mempool_populate_default(); > > What about introducing an API like: > rte_pktmbuf_poll_create_with_ops (..., ops_name, config_pool); > > I think that API would help for the case the application wants an mbuf pool > with ie. stack handler. > Sure we can do the empty/set_ops/populate sequence, but the only thing we > want to change from default pktmbuf_pool_create API is the pool handler. > > Application just needs to decide the ops handler to use, either default or > one suggested by PMD? > > I think ideally we would have similar APIs: > - rte_mempool_create_with_ops (...) > - rte_memppol_xmem_create_with_ops (...) > Olivier, What do you think? No strong opion but Can we please close/agree on API? I don't want to keep rebasing and pushing new variant in every other version, This whole series and its dependent series ie..octeontx PMD/FPA PMD taregeted for -rc1-v17.11 release therefore if we close on api and get it reviewed by this week, would really appreciate. Thanks. > > Thanks, > Sergio > >> Change History: >> v2 --> v3: >> - Changed version.map from DPDK_17.08 to DPDK_17.11. >> >> v1 --> v2: >> - Renamed rte_eal_get_mempool_name to rte_eal_mbuf_default_mempool_ops(). >> (suggested by Olivier) >> - Renamed _get_preferred_pool to _get_preferred_pool_ops(). >> - Updated API description and changes return val from -EINVAL to -ENOTSUP. >> (Suggested by Olivier) >> * Specific details on v1-->v2 change summary described in each patch. >> >> Checkpatch status: >> - None. >> >> Work History: >> * Refer [1] for v1. >> >> Thanks. >> >> [1] http://dpdk.org/ml/archives/dev/2017-June/067022.html >> >> >> Santosh Shukla (2): >> eal: allow user to override default pool handle >> ethdev: allow pmd to advertise pool handle >> >> lib/librte_eal/bsdapp/eal/eal.c | 17 +++++++++++++++++ >> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 7 +++++++ >> lib/librte_eal/common/eal_common_options.c | 5 +++++ >> lib/librte_eal/common/eal_internal_cfg.h | 1 + >> lib/librte_eal/common/eal_options.h | 2 ++ >> lib/librte_eal/common/include/rte_eal.h | 11 +++++++++++ >> lib/librte_eal/linuxapp/eal/eal.c | 18 ++++++++++++++++++ >> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 7 +++++++ >> lib/librte_ether/rte_ethdev.c | 18 ++++++++++++++++++ >> lib/librte_ether/rte_ethdev.h | 21 +++++++++++++++++++++ >> lib/librte_ether/rte_ether_version.map | 7 +++++++ >> lib/librte_mbuf/rte_mbuf.c | 5 +++-- >> 12 files changed, 117 insertions(+), 2 deletions(-) >> >
