From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH] mbuf: reduce pktmbuf init cycles
Date: Fri, 23 Jun 2017 15:36:44 +0530 [thread overview]
Message-ID: <20170623100642.GA25523@jerin> (raw)
In-Reply-To: <20170623114230.54dadacd@platinum>
-----Original Message-----
> Date: Fri, 23 Jun 2017 11:42:30 +0200
> From: Olivier Matz <olivier.matz@6wind.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> 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 <jerin.jacob@caviumnetworks.com> 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 <jerin.jacob@caviumnetworks.com>
> > ---
> > 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
next prev parent reply other threads:[~2017-06-23 10:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 16:38 [PATCH] mbuf: reduce pktmbuf init cycles Jerin Jacob
2017-06-23 9:42 ` Olivier Matz
2017-06-23 10:06 ` Jerin Jacob [this message]
2017-06-27 11:57 ` [PATCH v2] " Jerin Jacob
2017-06-30 12:27 ` Olivier Matz
2017-07-01 10:15 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170623100642.GA25523@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.