From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 86C338D8F for ; Fri, 18 Dec 2015 08:10:44 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 17 Dec 2015 23:10:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,445,1444719600"; d="scan'208";a="874063302" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga002.jf.intel.com with ESMTP; 17 Dec 2015 23:10:33 -0800 Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Dec 2015 23:10:32 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Dec 2015 23:10:32 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.190]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.92]) with mapi id 14.03.0248.002; Fri, 18 Dec 2015 15:10:30 +0800 From: "Xie, Huawei" To: Stephen Hemminger Thread-Topic: [dpdk-dev] [PATCH v2 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API Thread-Index: AdE5Yy0W5k4AFZq3TfmHtb59BK82Zg== Date: Fri, 18 Dec 2015 07:10:29 +0000 Message-ID: References: <1450049754-33635-1-git-send-email-huawei.xie@intel.com> <1450055682-51953-1-git-send-email-huawei.xie@intel.com> <1450055682-51953-2-git-send-email-huawei.xie@intel.com> <20151217210114.534a7561@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 1/2] mbuf: provide rte_pktmbuf_alloc_bulk API 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: Fri, 18 Dec 2015 07:10:45 -0000 On 12/18/2015 1:03 PM, Stephen Hemminger wrote:=0A= > On Mon, 14 Dec 2015 09:14:41 +0800=0A= > Huawei Xie wrote:=0A= >=0A= >> v2 changes:=0A= >> unroll the loop a bit to help the performance=0A= >>=0A= >> rte_pktmbuf_alloc_bulk allocates a bulk of packet mbufs.=0A= >>=0A= >> There is related thread about this bulk API.=0A= >> http://dpdk.org/dev/patchwork/patch/4718/=0A= >> Thanks to Konstantin's loop unrolling.=0A= >>=0A= >> Signed-off-by: Gerald Rogers =0A= >> Signed-off-by: Huawei Xie =0A= >> Acked-by: Konstantin Ananyev =0A= >> ---=0A= >> lib/librte_mbuf/rte_mbuf.h | 50 +++++++++++++++++++++++++++++++++++++++= +++++++=0A= >> 1 file changed, 50 insertions(+)=0A= >>=0A= >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h=0A= >> index f234ac9..4e209e0 100644=0A= >> --- a/lib/librte_mbuf/rte_mbuf.h=0A= >> +++ b/lib/librte_mbuf/rte_mbuf.h=0A= >> @@ -1336,6 +1336,56 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(= struct rte_mempool *mp)=0A= >> }=0A= >> =0A= >> /**=0A= >> + * Allocate a bulk of mbufs, initialize refcnt and reset the fields to = default=0A= >> + * values.=0A= >> + *=0A= >> + * @param pool=0A= >> + * The mempool from which mbufs are allocated.=0A= >> + * @param mbufs=0A= >> + * Array of pointers to mbufs=0A= >> + * @param count=0A= >> + * Array size=0A= >> + * @return=0A= >> + * - 0: Success=0A= >> + */=0A= >> +static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,=0A= >> + struct rte_mbuf **mbufs, unsigned count)=0A= >> +{=0A= >> + unsigned idx =3D 0;=0A= >> + int rc;=0A= >> +=0A= >> + rc =3D rte_mempool_get_bulk(pool, (void **)mbufs, count);=0A= >> + if (unlikely(rc))=0A= >> + return rc;=0A= >> +=0A= >> + switch (count % 4) {=0A= >> + while (idx !=3D count) {=0A= >> + case 0:=0A= >> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) =3D=3D 0);=0A= >> + rte_mbuf_refcnt_set(mbufs[idx], 1);=0A= >> + rte_pktmbuf_reset(mbufs[idx]);=0A= >> + idx++;=0A= >> + case 3:=0A= >> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) =3D=3D 0);=0A= >> + rte_mbuf_refcnt_set(mbufs[idx], 1);=0A= >> + rte_pktmbuf_reset(mbufs[idx]);=0A= >> + idx++;=0A= >> + case 2:=0A= >> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) =3D=3D 0);=0A= >> + rte_mbuf_refcnt_set(mbufs[idx], 1);=0A= >> + rte_pktmbuf_reset(mbufs[idx]);=0A= >> + idx++;=0A= >> + case 1:=0A= >> + RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) =3D=3D 0);=0A= >> + rte_mbuf_refcnt_set(mbufs[idx], 1);=0A= >> + rte_pktmbuf_reset(mbufs[idx]);=0A= >> + idx++;=0A= >> + }=0A= >> + }=0A= >> + return 0;=0A= >> +}=0A= > This is weird. Why not just use Duff's device in a more normal manner.=0A= Hi Stephen: I just compared with duff's unrolled version. It is slightly=0A= different, but where is weird?=0A= >=0A= >=0A= =0A=