From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by dpdk.org (Postfix) with ESMTP id 47B985953 for ; Tue, 28 Jan 2014 02:26:51 +0100 (CET) Received: from mail-vb0-f43.google.com ([209.85.212.43]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (auth plain:sangjin@berkeley.edu) (envelope-from ) id 1W7xTD-0004bz-6x for dev@dpdk.org; Mon, 27 Jan 2014 17:28:08 -0800 Received: by mail-vb0-f43.google.com with SMTP id p5so3969716vbn.30 for ; Mon, 27 Jan 2014 17:28:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NiYdSPefqNIp6/9ywl24tHTsCDCOmJeUQMSxsrmlD+g=; b=gkCZ9QT3VYzNGCP4AuAWhsJJg/6DCmFqSUThYc6WeBPbPHLh2sar6MNOBta8iNMHcv FxpBhBhfTwkPxRCw77oVksZ+Es7lSYePPU7/2mok46j8yMeCtvwWwozx21tofmky18Ao 0exgPH1gOLE5cNkxJvBpSv9A56yh8KtjzPzBk2ge3Aj4bVh2nb9uBPGbdobkml4OpkEU 4td7MXEBgYZsXP8qQdPQ/Dd19TERJ4pmKQO6QOU1rv4R03C0eGm3x4SNkU4tCtgTm3V5 NDIzXjFpqd8TP/tAFDNOs9j1L3JvAZGJYMDHvS1iw5Gcc0V3FTH0feAUxoVRI4cvzF4B ieLw== MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr18217904vcb.0.1390872486252; Mon, 27 Jan 2014 17:28:06 -0800 (PST) Received: by 10.220.73.137 with HTTP; Mon, 27 Jan 2014 17:28:06 -0800 (PST) In-Reply-To: <52E649CD.3090000@6wind.com> References: <1390562277-24769-1-git-send-email-didier.pallard@6wind.com> <00d201cf18f9$67cdaf10$37690d30$@com> <201401271057.52251.thomas.monjalon@6wind.com> <52E649CD.3090000@6wind.com> Date: Mon, 27 Jan 2014 17:28:06 -0800 Message-ID: From: Sangjin Han To: "didier.pallard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] timer: add lfence before TSC read X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 01:26:52 -0000 Why LFENCE, rather than CPUID? I guess LFENCE does not prevent out-of-order execution for non-load instructions across it. This link has detailed information on RDTSC, RDTSCP, and CPUID: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia= -32-ia-64-benchmark-code-execution-paper.pdf Sangjin On Mon, Jan 27, 2014 at 3:58 AM, didier.pallard wrote: > Yes, i will add a new function that includes the lfence; > > for the performance penalty, we did not see noticable performance impact = on > our full software, so we did not see any reason to use 2 functions, but i= t's > certainly because we make a very limited number of calls to rdtsc and it'= s > true that it is highly application dependant, so 2 functions are probably > better. But if using the unaccurate function, you may have some hard time > the first time you want to debug or do some precise measures, since the > measure is not always done when expected. And generally, especially when > debugging, you're not focusing at first on the function you're using to > debug... > i don't know how to do to be sure that people will be aware of the proble= m > and do not lose time on the same problem, i will try to add some kind of > warning in rte_rdtsc function itself. > But perhaps should it be better to use the precise version as default one > and let the optimized version with another name to be use on purpose when > accuracy is not important; By default, i think we generaly suppose a time > reading function to be accurate... > > thanks > didier > > > On 01/27/2014 10:57 AM, Thomas Monjalon wrote: >> >> 24/01/2014 12:42, Fran=E7ois-Fr=E9d=E9ric Ozog: >>> >>> 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 comme= nt >>> about the rdtsc instruction behavior so that developers can choose whic= h >>> form they want? >> >> Yes it could be a good idea in some cases. Didier, could you try to add >> such >> function ? >> >> But in some debugging cases we need to have high precision for almost al= l >> timestamps. Here I don't know what is the smartest solution. >> >> Thank you for commenting. Hope we'll find a good fix. > > >