Hi Olivier

On 9/19/2016 7:27 PM, Olivier Matz wrote:

Hi Hemant,

On 09/16/2016 06:46 PM, Hemant Agrawal wrote:

quoted

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