[dpdk-dev] [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

Hi Olivier

On 9/19/2016 7:27 PM, Olivier Matz wrote:
> 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.
>
It will be bit late.

On failure, than we have to set the default ops and do a goto before
rte_pktmbuf_pool_init(mp, &mbp_priv);


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

We ran into this issue when trying to run the standard DPDK examples 
(l3fwd) in VM. Do you think, is it practical to add fallback handling in 
each of the DPDK examples?

Typically when someone is writing a application on host, he need not 
worry non-availability of the hw offloaded mempool. He may also want to 
run the same binary in virtual machine. In VM, it is not guaranteed that 
hw offloaded mempools will be available.

w.r.t your RFC, we can do this:
if the user has specified a mempool_ops in rte_pktmbuf_pool_create(), 
don't fallback. It will be responsibility for application to decide on 
calling again rte_pktmbuf_pool_create() with different mempool_ops.

>
>
> Regards,
> Olivier
>