Hi Hemant,
On Sunday 04 February 2018 11:52 AM, Shukla, Santosh wrote:
> The existing rte_eal_mbuf_default mempool ops can return the compile time
> default ops name if the user has not provided command line inputs for
> mempool ops name. It will break the logic of best mempool ops as it will
> never return platform hw mempool ops.
>
> This patch introduces a new API to just return the user mempool ops only.
>
> Fixes: 8b0f7f434132 ("mbuf: maintain user and compile time mempool ops name")
>
> Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
> ---
This patch introduces regression for octeontx platform.
Fails with:
---------
testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=163456, size=2176,
socket=0
testpmd: preferred mempool ops selected: dpaa
dpaa_mbuf_create_pool(): bman_new_pool() failed
EAL: Error - exiting with code: 1
----------
Command:
./testpmd -c 0xe00000 -n 4 -- --portmask 0x1 --nb-cores=2
--port-topology=loop --rxq=2 --txq=2 --rss-ip --no-flush-rx
-------------
It's because rte_dpaa_bus_probe() sets platform mempool ops
i.e. rte_mbuf_set_platform_mempool_ops(DPAA_MEMPOOL_OPS_NAME);
therefore `rte_mbuf_best_mempool_ops` returns with `dpaa` ops which
is incorrect mempool_ops choice for octeontx platform.
We can fix such regression with following ways:
# option 1) unset LIBRTE_DPAA_MEMPOOL=y from common_armv8a_linuxapp config and
set at dpaa/dpaa2 specific configs
commit: 1ee9569576f6 ("config: enable dpaaX drivers for generic ARMv8")
# option 2) Don;t set platform mempool ops in dpaa bus layer instead defer it
to driver layer.
Thanks.
