From: "François-Frédéric Ozog" <ff@ozog.com>
To: "'Didier Pallard'" <didier.pallard@6wind.com>, <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] timer: add lfence before TSC read
Date: Fri, 24 Jan 2014 12:42:47 +0100 [thread overview]
Message-ID: <00d201cf18f9$67cdaf10$37690d30$@com> (raw)
In-Reply-To: <1390562277-24769-1-git-send-email-didier.pallard@6wind.com>
Hi,
Most of the time rdtsc is used for timestamping and a few cycles incorrect
are most of the time not an issue (a precision of 0.1us for session start is
usually enough).
Sometimes you need to serialize because the time you want to measure is very
short, in the order of few nanoseconds.
If the code is running in a VM, which usually virtualize rdtsc instruction,
then it even make no sense to have more "precision".
IMHO, adding the lfence for all cases is introducing an un-necessary
performance penalty.
What about adding rte_rdtsc_sync() or rte_rdtsc_serial() with the comment
about the rdtsc instruction behavior so that developers can choose which
form they want?
François-Frédéric
> -----Message d'origine-----
> De : dev [mailto:dev-bounces@dpdk.org] De la part de Didier Pallard
> Envoyé : vendredi 24 janvier 2014 12:18
> À : dev@dpdk.org
> Objet : [dpdk-dev] [PATCH] timer: add lfence before TSC read
>
> According to Intel Developer's Manual:
>
> "The RDTSC instruction is not a serializing instruction. It does not
> necessarily wait until all previous instructions have been executed
before
> reading the counter. Simi- larly, subsequent instructions may begin
> execution before the read operation is performed. If software requires
> RDTSC to be executed only after all previous instruc- tions have
completed
> locally, it can either use RDTSCP (if the processor supports that
> instruction) or execute the sequence LFENCE;RDTSC."
>
> So add a lfence instruction before rdtsc to synchronize read operations
and
> ensure that the read is done at the expected instant.
>
> Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
> ---
> lib/librte_eal/common/include/rte_cycles.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/librte_eal/common/include/rte_cycles.h
> b/lib/librte_eal/common/include/rte_cycles.h
> index cc6fe71..487dba6 100644
> --- a/lib/librte_eal/common/include/rte_cycles.h
> +++ b/lib/librte_eal/common/include/rte_cycles.h
> @@ -110,6 +110,9 @@ rte_rdtsc(void)
> };
> } tsc;
>
> + /* serialize previous load instructions in pipe */
> + asm volatile("lfence");
> +
> #ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
> if (unlikely(rte_cycles_vmware_tsc_map)) {
> /* ecx = 0x10000 corresponds to the physical TSC for VMware
*/
> --
> 1.7.10.4
next prev parent reply other threads:[~2014-01-24 11:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 11:17 Didier Pallard
2014-01-24 11:42 ` François-Frédéric Ozog [this message]
2014-01-24 12:48 ` Ananyev, Konstantin
2014-01-27 9:57 ` Thomas Monjalon
2014-01-27 11:58 ` didier.pallard
2014-01-28 1:28 ` Sangjin Han
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='00d201cf18f9$67cdaf10$37690d30$@com' \
--to=ff@ozog.com \
--cc=dev@dpdk.org \
--cc=didier.pallard@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).