From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Matz Subject: Re: [PATCH] mbuf: reduce pktmbuf init cycles Date: Fri, 23 Jun 2017 11:42:30 +0200 Message-ID: <20170623114230.54dadacd@platinum> References: <20170605163807.31941-1-jerin.jacob@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Jerin Jacob Return-path: Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by dpdk.org (Postfix) with ESMTP id BAE452C37 for ; Fri, 23 Jun 2017 11:42:33 +0200 (CEST) Received: by mail-wr0-f181.google.com with SMTP id r103so57988287wrb.0 for ; Fri, 23 Jun 2017 02:42:33 -0700 (PDT) In-Reply-To: <20170605163807.31941-1-jerin.jacob@caviumnetworks.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. Olivier