From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>,
"dev@dpdk.org" <dev@dpdk.org>,
"Bruce Richardson" <bruce.richardson@intel.com>
Cc: Jan Viktorin <viktorin@rehivetech.com>,
Ruifeng Wang <ruifeng.wang@arm.com>,
David Christensen <drc@linux.vnet.ibm.com>,
"Stanislaw Kardach" <kda@semihalf.com>
Subject: RE: [RFC v2] non-temporal memcpy
Date: Fri, 29 Jul 2022 19:49:07 +0000 [thread overview]
Message-ID: <66b6efccde5b4d68bffcc47713cdf983@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87211@smartserver.smartshare.dk>
>
> > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > Sent: Friday, 29 July 2022 14.14
> >
> >
> > Sorry, missed that part.
> >
> > >
> > > > Another question - who will do 'sfence' after the copying?
> > > > Would it be inside memcpy_nt (seems quite costly), or would
> > > > it be another API function for that: memcpy_nt_flush() or so?
> > >
> > > Outside. Only the developer knows when it is required, so it wouldn't
> > make any sense to add the cost inside memcpy_nt().
> > >
> > > I don't think we should add a flush function; it would just be
> > another name for an already existing function. Referring to the
> > required
> > > operation in the memcpy_nt() function documentation should suffice.
> > >
> >
> > Ok, but again wouldn't it be arch specific?
> > AFAIK for x86 it needs to boil down to sfence, for other architectures
> > - I don't know.
> > If you think there already is some generic one (rte_wmb?) that would
> > always produce
> > correct instructions - sure let's use it.
> >
>
> DPDK has generic functions to wrap architecture specific stuff like memory barriers.
>
> Because they are non-temporal stores, I suspect that rte_mb() is required before reading the data from the location it was copied to.
> Ensuring that STORE operations are ordered (rte_wmb) might not suffice. However, I'm not a CPU expert, so I will seek advice from
> more qualified people in the community on this.
I think for IA sfence is enough, see citation below,
for other architectures - no idea.
What I am trying to say - it needs to be the *same* function on all archs we support.
IA SW optimization manual:
9.4.2 Streaming Store Usage Models
The two primary usage domains for streaming store are coherent requests and non-coherent requests.
9.4.2.1 Coherent Requests
Coherent requests are normal loads and stores to system memory, which may also hit cache lines
present in another processor in a multiprocessor environment. With coherent requests, a streaming store
can be used in the same way as a regular store that has been mapped with a WC memory type (PAT or
MTRR). An SFENCE instruction must be used within a producer-consumer usage model in order to ensure
coherency and visibility of data between processors.
Within a single-processor system, the CPU can also re-read the same memory location and be assured of
coherence (that is, a single, consistent view of this memory location). The same is true for a multiprocessor
(MP) system, assuming an accepted MP software producer-consumer synchronization policy is
employed.
next prev parent reply other threads:[~2022-07-29 19:49 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 15:26 [RFC v2] non-temporal memcpy Morten Brørup
2022-07-19 18:00 ` David Christensen
2022-07-19 18:41 ` Morten Brørup
2022-07-19 18:51 ` Stanisław Kardach
2022-07-19 22:15 ` Morten Brørup
2022-07-21 23:19 ` Konstantin Ananyev
2022-07-22 10:44 ` Morten Brørup
2022-07-24 13:35 ` Konstantin Ananyev
2022-07-24 22:18 ` Morten Brørup
2022-07-29 10:00 ` Konstantin Ananyev
2022-07-29 10:46 ` Morten Brørup
2022-07-29 11:50 ` Konstantin Ananyev
2022-07-29 17:17 ` Morten Brørup
2022-07-29 22:00 ` Konstantin Ananyev
2022-07-30 9:51 ` Morten Brørup
2022-08-02 9:05 ` Konstantin Ananyev
2022-07-29 12:13 ` Konstantin Ananyev
2022-07-29 16:05 ` Stephen Hemminger
2022-07-29 17:29 ` Morten Brørup
2022-08-07 20:40 ` Mattias Rönnblom
2022-08-09 9:24 ` Morten Brørup
2022-08-09 11:53 ` Mattias Rönnblom
2022-10-09 16:16 ` Morten Brørup
2022-07-29 18:13 ` Morten Brørup
2022-07-29 19:49 ` Konstantin Ananyev [this message]
2022-07-29 20:26 ` Morten Brørup
2022-07-29 21:34 ` Konstantin Ananyev
2022-08-07 20:20 ` Mattias Rönnblom
2022-08-09 9:34 ` Morten Brørup
2022-08-09 11:56 ` Mattias Rönnblom
2022-08-10 21:05 ` Honnappa Nagarahalli
2022-08-11 11:50 ` Mattias Rönnblom
2022-08-11 16:26 ` Honnappa Nagarahalli
2022-07-25 1:17 ` Honnappa Nagarahalli
2022-07-27 10:26 ` Morten Brørup
2022-07-27 17:37 ` Honnappa Nagarahalli
2022-07-27 18:49 ` Morten Brørup
2022-07-27 19:12 ` Stephen Hemminger
2022-07-28 9:00 ` Morten Brørup
2022-07-27 19:52 ` Honnappa Nagarahalli
2022-07-27 22:02 ` Stanisław Kardach
2022-07-28 10:51 ` Morten Brørup
2022-07-29 9:21 ` Konstantin Ananyev
2022-08-07 20:25 ` Mattias Rönnblom
2022-08-09 9:46 ` Morten Brørup
2022-08-09 12:05 ` Mattias Rönnblom
2022-08-09 15:00 ` Morten Brørup
2022-08-10 11:47 ` Mattias Rönnblom
2022-08-09 15:26 ` Stephen Hemminger
2022-08-09 17:24 ` Morten Brørup
2022-08-10 11:59 ` Mattias Rönnblom
2022-08-10 12:12 ` Morten Brørup
2022-08-10 11:55 ` Mattias Rönnblom
2022-08-10 12:18 ` Morten Brørup
2022-08-10 21:20 ` Honnappa Nagarahalli
2022-08-11 11:53 ` Mattias Rönnblom
2022-08-11 22:24 ` Honnappa Nagarahalli
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=66b6efccde5b4d68bffcc47713cdf983@huawei.com \
--to=konstantin.ananyev@huawei.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=drc@linux.vnet.ibm.com \
--cc=kda@semihalf.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=mb@smartsharesystems.com \
--cc=ruifeng.wang@arm.com \
--cc=viktorin@rehivetech.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.