From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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=WCXcfqBg4USmmee4dSE2YtbCC8PSLXSzvPuQkTyd8EI=; b=cgGuWKBUm+jTAvbZKa1l3oM+2eG2oM87ChSk/429PlqYjsbaEnnhjWylZaCQZ3SW/z njAXySWgtyV5hTX+A+gWN+1ldYqvQ/vTyNVSuys2E/SX79/VXfjD4DhlWDrAHLvwJZSn y777yQ+nlT0KPXOLXUR8bZoWf1fwe+aZ5Kczu6pf21EGAzZyikz329VVkqGMpL1qW4Z/ EdofgvRpsSS7y4Dfx5PVTDJkFMijbC1pKt9A7khBQMvTX7X79N1jkyJfe1QdDt2pzVAr IyQhDs5kBtFYEMBl1giWzNSwHe9ly7RTOtJCnUyaOx+0J0FI0R1d179cTakMZZWY0Ixf 8rVA== 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=WCXcfqBg4USmmee4dSE2YtbCC8PSLXSzvPuQkTyd8EI=; b=pUhTeiDQmoHwvb3y6iiyfeUGNxntMcOPwh2EFq7SEHoeEPFtr216brb6jzXXynl+Dp jFSNgx9AsAWzHn/5bABAa5BnFRlXMz0Kjoy0g6lz7LRGGk1EYjYqTlwqdCBoVuh3ggQs hAhQ7QtubAfJozbluMm4aeYakZkYLhWeIwEidLklFKzA2VDBVvvMiYoHt0Fx2Ug3i6Vv nbTJO/fBVgQnkgFlBBhuXJg3Uy++I6nsjy/jHrpJYMArvC2C9V0QqekQAmr6mDfvv3vO NF8eXGFUmFxlKcbxmKhAYG2QxKMsB6w0XamDtdQL1eD4SIs4bfIorcTufhfv7O0QnfPo va0w== X-Gm-Message-State: AKS2vOxT7ntvh5uX2L5XYl7lK3jNWTg9rBR/Tl0qRvd+yDauG6YaubP8 KHJ1V0PFb9AjTt+UkWY= X-Received: by 10.223.128.141 with SMTP id 13mr5603310wrl.141.1498210953351; Fri, 23 Jun 2017 02:42:33 -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 k12sm5633800wrc.10.2017.06.23.02.42.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Jun 2017 02:42:33 -0700 (PDT) Date: Fri, 23 Jun 2017 11:42:30 +0200 From: Olivier Matz To: Jerin Jacob Cc: dev@dpdk.org Message-ID: <20170623114230.54dadacd@platinum> In-Reply-To: <20170605163807.31941-1-jerin.jacob@caviumnetworks.com> References: <20170605163807.31941-1-jerin.jacob@caviumnetworks.com> 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] mbuf: reduce pktmbuf init cycles 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: Fri, 23 Jun 2017 09:42:34 -0000 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