From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id 7A84E152A for ; Mon, 27 Mar 2017 18:30:57 +0200 (CEST) Received: by mail-wr0-f180.google.com with SMTP id u1so64789666wra.2 for ; Mon, 27 Mar 2017 09:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=UYNZRETT9hzQ8ERxRr69Wgo90L6JDb8qrFQwMTU+5Aw=; b=YwkWUz5y7GHC20dzuW3TbpGbatLQt7E1zmhiI1BFbETCaT+9W7+QAWPCil+DvZa1Gb 0omoJM0Z/UzbCr7JbjuAr/timSi4WS0lxp9LWQ4Gb0BtZ4GsQ5RKEr0NDwanic7jLojW EsBVoAGqGcjx8qS0W4xAJCt3Dc3IVqJ4uK5c5BelpjCmaBVHjoJiL3saUMhSEz16woT6 Bdznsu0myLU5ownA3nBt83I6jMI1inKPR3vVxAJjsZG0D8nZHBB+37Zv1sFuShQTaZWo 1NKtS1j50NLrk35+LdZ9gG0VATQ18KJrdmcu9x9xhuyD2gRq8TT6fJgcqh9cMCH5ecfA 9cqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=UYNZRETT9hzQ8ERxRr69Wgo90L6JDb8qrFQwMTU+5Aw=; b=hekap145lo76BfWZuezIA4xNtVDcckNNtrntsKqiAjONk79RFJBMsHr3RsGWMEbupX Yklaqow/UAYMiTTN/lMFH6vlDz/jwcxMOM+MoFIajbTV432Wfw1i9aAY725a/0yWXTJp iZatS24RDNZAtc02r1jaWpnJGxyF8/smcfoekJpNiNw+MDW6vOdNAmYpQ5Xs9yjrwaJo T2t0oRY196ZTkTZJ3egTg+O0B8ODvYN7lupf0F+GPREgfhby5HeebJi+jRt2519YXoSJ t7E92j3hlw1Onl36yS4neuVBJcL5c73gi4KSz6aOuU1qntaOTKURh8ICyMy+rX+bm2An a3kQ== X-Gm-Message-State: AFeK/H0d6M7/t2JiPA6r3T8Bhns40gplfXYn0dPuAXWcXCawNug5B7LFqjPMzCCKFS8NmXif X-Received: by 10.28.29.138 with SMTP id d132mr10170286wmd.40.1490632257204; Mon, 27 Mar 2017 09:30:57 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id b199sm91581wmb.13.2017.03.27.09.30.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Mar 2017 09:30:57 -0700 (PDT) Date: Mon, 27 Mar 2017 18:30:52 +0200 From: Olivier Matz To: Ferruh Yigit Cc: Hemant Agrawal , dev@dpdk.org, thomas.monjalon@6wind.com, shreyansh.jain@nxp.com Message-ID: <20170327183052.0fb0614c@platinum> In-Reply-To: <20170324174246.4d04a21f@platinum> References: <1489754838-1455-1-git-send-email-hemant.agrawal@nxp.com> <1489754838-1455-2-git-send-email-hemant.agrawal@nxp.com> <7d898278-9331-0c72-cabd-9318c6d65f1e@intel.com> <5af16ee7-fdcc-5b03-0897-f0657e8f8e7f@intel.com> <20170324173146.477a5157@platinum> <434e5f68-430b-1676-fed8-3527f25f3081@intel.com> <20170324174246.4d04a21f@platinum> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v1] mempool/dpaa2: add DPAA2 hardware offloaded mempool X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:30:57 -0000 Hi Hemant, On Fri, 24 Mar 2017 17:42:46 +0100, Olivier Matz wrote: > > > From high level, I'm still a little puzzled by the amount of references > > > to mbuf in a mempool handler code, which should theorically handle any > > > kind of objects. > > > > > > Is it planned to support other kind of objects? > > > Does this driver passes the mempool autotest? > > > Can the user be aware of these limitations? Some more comments. I think the mempool model as it is today in DPDK does not match your driver model. For instance, the fact that the hardware is able return the mbuf in the pool by itself makes me think that the mbuf rework patchset [1] can break your driver. Especially this patch [2], that expects that m->refcnt=1, m->nb_segs=1 and m->next=NULL when allocating from a pool. - Can this handler can be used with another driver? - Can your driver be used with another mempool handler? - Is the dpaa driver the only driver that would take advantage of the mempool handler? Will it work with cloned mbufs? Defining a flag like this in your private code should not be done: #define MEMPOOL_F_HW_PKT_POOL (1 << ((sizeof(int) * 8) - 1)) Nothing prevents to break it if someone touches the generic flags in mempool. And hope that no other driver does the same :) Maybe you can do the same without flag, for instance by checking if (m->pool == pmd->pool)? I think a new mempool handler should pass the mempool tests, or at least we should add a new API that would describe the capabilities or something like that (for instance: support mbuf pool only, support multiprocess). To conclude, I'm quite reserved. Well, all the code is in driver/, meaning it does not pollute the rest. Regards, Olivier [1] http://dpdk.org/ml/archives/dev/2017-March/059693.html [2] http://dpdk.org/dev/patchwork/patch/21602/