From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Jianbo Liu <jianbo.liu@linaro.org>
Cc: Olivier MATZ <olivier.matz@6wind.com>, <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] mbuf: extend rte_mbuf_prefetch_part* to support more prefetching methods
Date: Thu, 2 Jun 2016 15:00:08 +0530 [thread overview]
Message-ID: <20160602093006.GA6794@localhost.localdomain> (raw)
In-Reply-To: <CAP4Qi380Jkq_1DE2pF1YyvMDXc7NPri8yvik4E4mB3_cJnAMLg@mail.gmail.com>
On Thu, Jun 02, 2016 at 05:04:13PM +0800, Jianbo Liu wrote:
> On 1 June 2016 at 14:00, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > On Wed, Jun 01, 2016 at 11:29:47AM +0800, Jianbo Liu wrote:
> >> On 1 June 2016 at 03:28, Olivier MATZ <olivier.matz@6wind.com> wrote:
> >> > Hi Jianbo,
> >> >
> >> > On 05/31/2016 05:06 AM, Jianbo Liu wrote:
> >> >> Change the inline function to macro with parameters
> >> >>
> >> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> >> >>
> >> >> [...]
> [...]
> >> It's for performance consideration, and only on armv8a platform.
> >
> > Strictly it is not armv8 specific, IA also implemented this API with
> > _MM_HINT_NTA hint.
>
> I mean this patch is only for ixgbe vector PMD on armv8 platform.
>
> >
> > Do we really need non-temporal/transient version of prefetch for ixgbe?
>
> Strictly speaking, we don't have to since we don't know how APPs use
> the mbuf header.
Then IMO it makes sense to keep the same behavior as x86 ixgbe driver.
Then on the upside, We may not need the new macros for part prefetching
Jerin
> But, is it high possibility that the second part is used only once or
> short period because prefetching is done only when split_packet is not
> NULL?
>
> > If so, for x86 also it makes sense to keep it? Right?
> >
> > The primary use case for transient version would be use with pipe line
> > line mode where the same cpu wont consume the packet.
> >
> > /**
> > * Prefetch a cache line into all cache levels (non-temporal/transient
> > * version)
> > *
> > * The non-temporal prefetch is intended as a prefetch hint that
> > * processor will
> > * use the prefetched data only once or short period, unlike the
> > * rte_prefetch0() function which imply that prefetched data to use
> > * repeatedly.
> > *
> > * @param p
> > * Address to prefetch
> > */
> > static inline void rte_prefetch_non_temporal(const volatile void *p);
> >
> >>
> >> >
> >> > By the way, I did not try to apply the patch, but it looks
> >> > it's on top of dpdk-next-net/rel_16_07, right?
> >> >
> >> Yes
next prev parent reply other threads:[~2016-06-02 9:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 3:06 Jianbo Liu
2016-05-31 19:28 ` Olivier MATZ
2016-06-01 3:29 ` Jianbo Liu
2016-06-01 6:00 ` Jerin Jacob
2016-06-02 9:04 ` Jianbo Liu
2016-06-02 9:30 ` Jerin Jacob [this message]
2016-06-21 14:56 ` Olivier Matz
2016-06-02 7:10 ` Olivier MATZ
2016-06-02 9:12 ` Jianbo Liu
2016-05-31 20:00 ` Stephen Hemminger
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=20160602093006.GA6794@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=dev@dpdk.org \
--cc=jianbo.liu@linaro.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 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).