From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <didier.pallard@6wind.com>
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com
 [74.125.82.178]) by dpdk.org (Postfix) with ESMTP id 593AA5320
 for <dev@dpdk.org>; Mon, 27 Jan 2014 12:56:50 +0100 (CET)
Received: by mail-we0-f178.google.com with SMTP id t60so5028368wes.23
 for <dev@dpdk.org>; Mon, 27 Jan 2014 03:58:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:organization:user-agent
 :mime-version:to:cc:subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=+DU2NL1ufIa08tPrbY7UlQ2V2f1NsgUrSe28CIcC/x4=;
 b=PgH5T+RhY+V/zfe2nU14QV1T5n+8jq/lgDt8RT4KG46w3+FwtLA0eVK6xvX8wdEaIN
 Ls77d0ZjLU3NePbzPFqKwQTJo4TNG7fgv9TJ9t/CAnhercrmNb/Y2EQQfVtXMN4Dd7Gr
 p7lIDy+EBWxit7D3g+SvRIIL+ZHhNmV+zaVVu6SXqSED4jugkqYOQGjLUg2dGbdmsX6X
 K74eTe8QEme38LRQqK7czT3ONY7Hp+dCPo4l3xLmTOUQuRY0f8DbkFDB4nIQtkZDB85b
 bCUcHf2f8sKMVaNbtH5aEYRY8wizaIa7f6DcDrIJ8wWZXiFcCRtqZk+CWNd5J7Ua0Vc1
 j05g==
X-Gm-Message-State: ALoCoQnxRApEMXJQMTEF8uk1YBnp49fdrIdMTOj0iCexJ7pfMt7KURHPNdrAY60ZegKMv1+k5iha
X-Received: by 10.194.24.65 with SMTP id s1mr1673486wjf.38.1390823888221;
 Mon, 27 Jan 2014 03:58:08 -0800 (PST)
Received: from [10.16.0.123] (6wind.net2.nerim.net. [213.41.180.237])
 by mx.google.com with ESMTPSA id n3sm27229063wix.10.2014.01.27.03.58.06
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Mon, 27 Jan 2014 03:58:07 -0800 (PST)
Message-ID: <52E649CD.3090000@6wind.com>
Date: Mon, 27 Jan 2014 12:58:05 +0100
From: "didier.pallard" <didier.pallard@6wind.com>
Organization: 6wind
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:18.0) Gecko/20121128 Thunderbird/18.0
MIME-Version: 1.0
To: Thomas Monjalon <thomas.monjalon@6wind.com>
References: <1390562277-24769-1-git-send-email-didier.pallard@6wind.com>
 <00d201cf18f9$67cdaf10$37690d30$@com>
 <201401271057.52251.thomas.monjalon@6wind.com>
In-Reply-To: <201401271057.52251.thomas.monjalon@6wind.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 11:56:50 -0000

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 it'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 
problem 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çois-Frédéric 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 comment
>> about the rdtsc instruction behavior so that developers can choose which
>> 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 all
> timestamps. Here I don't know what is the smartest solution.
>
> Thank you for commenting. Hope we'll find a good fix.