From: Olivier Matz <olivier.matz@6wind.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: konstantin.ananyev@intel.com, bruce.richardson@intel.com,
dev@dpdk.org, Paul Emmerich <emmericp@net.in.tum.de>,
"Mike A. Polehn" <mike.a.polehn@intel.com>
Subject: Re: [dpdk-dev] [PATCH] prefetch second cacheline of mbufs on alloc
Date: Thu, 16 Feb 2017 16:16:08 +0100 [thread overview]
Message-ID: <20170216161608.6715803c@platinum> (raw)
In-Reply-To: <1666545.dgckzNb2Rl@xps13>
On Wed, 15 Feb 2017 09:44:35 +0100, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> Do we need to discuss again the prefetch calls inside DPDK
> or can we definitely close this kind of request?
> mbuf: http://dpdk.org/patch/4678/
> ethdev: http://dpdk.org/patch/8867/
>
About the mbuf prefetch, I suggest the topic can be closed:
The rte_pkt_mbuf_alloc() function is not necessarily called in a place
where we will write the second cache line, so the prefetch is not always
useful. Having prefetches in generic functions does not look to be a
good idea, especially in that case, knowing it's easy to do it in the
application.
Olivier
>
> 2015-07-20 10:02, Olivier MATZ:
> > Hi Thomas,
> >
> >
> > On 07/20/2015 03:00 AM, Thomas Monjalon wrote:
> > > Please Olivier,
> > > What is the status of this patch?
> >
> > From what I remember, the last mail was a comment from Konstantin
> > on another thread (but same topic):
> > http://dpdk.org/ml/archives/dev/2015-May/017633.html
> >
> >
> > Regards,
> > Olivier
> >
> >
> > >
> > > 2015-05-12 01:15, Paul Emmerich:
> > >> this improves the throughput of a simple tx-only application by
> > >> 11% in the full-featured ixgbe tx path and by 14% in the simple
> > >> tx path. ---
> > >> lib/librte_mbuf/rte_mbuf.h | 1 +
> > >> 1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/lib/librte_mbuf/rte_mbuf.h
> > >> b/lib/librte_mbuf/rte_mbuf.h index ab6de67..f6895b4 100644
> > >> --- a/lib/librte_mbuf/rte_mbuf.h
> > >> +++ b/lib/librte_mbuf/rte_mbuf.h
> > >> @@ -538,6 +538,7 @@ static inline struct rte_mbuf
> > >> *__rte_mbuf_raw_alloc(struct rte_mempool *mp) if
> > >> (rte_mempool_get(mp, &mb) < 0) return NULL;
> > >> m = (struct rte_mbuf *)mb;
> > >> + rte_prefetch0(&m->cacheline1);
> > >> RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(m) == 0);
> > >> rte_mbuf_refcnt_set(m, 1);
> > >> return (m);
> > >>
> > >
> > >
>
>
prev parent reply other threads:[~2017-02-16 15:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 23:15 Paul Emmerich
2015-07-20 1:00 ` Thomas Monjalon
2015-07-20 8:02 ` Olivier MATZ
2017-02-15 8:44 ` Thomas Monjalon
2017-02-16 15:16 ` Olivier Matz [this message]
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=20170216161608.6715803c@platinum \
--to=olivier.matz@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=emmericp@net.in.tum.de \
--cc=konstantin.ananyev@intel.com \
--cc=mike.a.polehn@intel.com \
--cc=thomas.monjalon@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).