From mboxrd@z Thu Jan 1 00:00:00 1970 From: "didier.pallard" Subject: Re: [PATCH] timer: add lfence before TSC read Date: Mon, 27 Jan 2014 12:58:05 +0100 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: dev-VfR2kkLFssw@public.gmane.org To: Thomas Monjalon Return-path: In-Reply-To: <201401271057.52251.thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Yes, i will add a new function that includes the lfence; for the performance penalty, we did not see noticable performance impact=20 on our full software, so we did not see any reason to use 2 functions,=20 but it's certainly because we make a very limited number of calls to=20 rdtsc and it's true that it is highly application dependant, so 2=20 functions are probably better. But if using the unaccurate function, you=20 may have some hard time the first time you want to debug or do some=20 precise measures, since the measure is not always done when expected.=20 And generally, especially when debugging, you're not focusing at first=20 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=20 problem and do not lose time on the same problem, i will try to add some=20 kind of warning in rte_rdtsc function itself. But perhaps should it be better to use the precise version as default=20 one and let the optimized version with another name to be use on purpose=20 when accuracy is not important; By default, i think we generaly suppose=20 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 comm= ent >> about the rdtsc instruction behavior so that developers can choose whi= ch >> 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 a= ll > timestamps. Here I don't know what is the smartest solution. > > Thank you for commenting. Hope we'll find a good fix.