Hi Hemant,
On 09/16/2016 06:46 PM, Hemant Agrawal wrote:
> In the rte_pktmbuf_pool_create, if the default external mempool is
> not available, the implementation can default to "ring_mp_mc", which
> is an software implementation.
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>
> ---
> Changes in V3:
> * adding warning message to say that falling back to default sw pool
> ---
> lib/librte_mbuf/rte_mbuf.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 4846b89..8ab0eb1 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -176,6 +176,14 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
>
> rte_errno = rte_mempool_set_ops_byname(mp,
> RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
> +
> + /* on error, try falling back to the software based default pool */
> + if (rte_errno == -EOPNOTSUPP) {
> + RTE_LOG(WARNING, MBUF, "Default HW Mempool not supported. "
> + "falling back to sw mempool \"ring_mp_mc\"");
> + rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL);
> + }
> +
> if (rte_errno != 0) {
> RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
> return NULL;
>
Without adding a new method ".supported()", the first call to
rte_mempool_populate() could return the same error ENOTSUP. In this
case, it is still possible to fallback.
I've just submitted an RFC, which I think is quite linked:
http://dpdk.org/ml/archives/dev/2016-September/046974.html
Assuming a new parameter "mempool_ops" is added to
rte_pktmbuf_pool_create(), would it make sense to fallback to
"ring_mp_mc"? What about just returning ENOTSUP? The application could
do the job and decide which sw fallback to use.
Regards,
Olivier
