From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH] mbuf: reduce pktmbuf init cycles Date: Fri, 23 Jun 2017 15:36:44 +0530 Message-ID: <20170623100642.GA25523@jerin> References: <20170605163807.31941-1-jerin.jacob@caviumnetworks.com> <20170623114230.54dadacd@platinum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org To: Olivier Matz Return-path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0074.outbound.protection.outlook.com [104.47.42.74]) by dpdk.org (Postfix) with ESMTP id C54772BC3 for ; Fri, 23 Jun 2017 12:07:30 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20170623114230.54dadacd@platinum> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Fri, 23 Jun 2017 11:42:30 +0200 > From: Olivier Matz > To: Jerin Jacob > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] mbuf: reduce pktmbuf init cycles > X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) > > On Mon, 5 Jun 2017 22:08:07 +0530, Jerin Jacob wrote: > > There is no need for initializing the complete > > packet buffer with zero as the packet data area will be > > overwritten by the NIC Rx HW anyway. > > > > The testpmd configures the packet mempool > > with around 180k buffers with > > 2176B size. In existing scheme, the init routine > > needs to memset around ~370MB vs the proposed scheme > > requires only around ~44MB on 128B cache aligned system. > > > > Useful in running DPDK in HW simulators/emulators, > > where millions of cycles have an impact on boot time. > > > > Signed-off-by: Jerin Jacob > > --- > > lib/librte_mbuf/rte_mbuf.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c > > index 0e3e36a58..1d5ce7816 100644 > > --- a/lib/librte_mbuf/rte_mbuf.c > > +++ b/lib/librte_mbuf/rte_mbuf.c > > @@ -131,8 +131,7 @@ rte_pktmbuf_init(struct rte_mempool *mp, > > RTE_ASSERT(mp->elt_size >= mbuf_size); > > RTE_ASSERT(buf_len <= UINT16_MAX); > > > > - memset(m, 0, mp->elt_size); > > - > > + memset(m, 0, mbuf_size + RTE_PKTMBUF_HEADROOM); > > /* start of buffer is after mbuf structure and priv data */ > > m->priv_size = priv_size; > > m->buf_addr = (char *)m + mbuf_size; > > Yes, I don't foresee any risk to do that. > > I'm just wondering why RTE_PKTMBUF_HEADROOM should be zeroed. > For example, rte_pktmbuf_free() does not touch the data either, so > after some packets processing, we also have garbage data in the > headroom. Yes. Headroom can be garbage as application pull the packet offset up and writes new header on encapsulation use case. I will the send v2 with clearing only mbuf area. > > Olivier