From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id B15A42A58 for ; Mon, 19 Sep 2016 15:58:01 +0200 (CEST) Received: from [37.165.97.108] (helo=[192.168.42.200]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1blz7z-0003oa-4x; Mon, 19 Sep 2016 16:00:59 +0200 To: Hemant Agrawal References: <1473959607-1951-1-git-send-email-hemant.agrawal@nxp.com> <1474044395-11627-1-git-send-email-hemant.agrawal@nxp.com> <1474044395-11627-2-git-send-email-hemant.agrawal@nxp.com> Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, david.hunt@intel.com From: Olivier Matz Message-ID: Date: Mon, 19 Sep 2016 15:57:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <1474044395-11627-2-git-send-email-hemant.agrawal@nxp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 13:58:01 -0000 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 > --- > 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