2015-08-27 09:38, Jerin Jacob:
> On Tue, Aug 25, 2015 at 02:03:13PM +0200, Thomas Monjalon wrote:
> > 2015-08-18 18:10, Jerin Jacob:
> > > --- a/app/test/test_red.c
> > > +++ b/app/test/test_red.c
> > > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686) ||
> > > defined(RTE_ARCH_X86_X32)
> > > #ifdef __PIC__
> > > asm volatile (
> > > "mov %%ebx, %%edi\n"
> > > @@ -155,6 +156,7 @@ static inline void rdtsc_prof_start(struct rdtsc_prof
> > > *p)
> > > #else
> > > asm( "cpuid" : : : "%eax", "%ebx", "%ecx", "%edx" );
> > > #endif
> > > +#endif
> > > p->clk_start = rte_rdtsc();
> >
> > The right fix would be to move that arch-specific code into an EAL
> > abstraction.
>
> I agree. I thought the same. But I am not able to understand why 'cpuid'
> instruction used here without any input/output parameters. What is the
> role of 'cpuid' instruction in this specific function and what to
> abstract in eal ?
It is explained here:
http://dpdk.org/ml/archives/dev/2014-January/001182.html
I think it can be replaced by rte_rdtsc_precise() which was implemented
after the above discussion. It uses rte_mb instead of cpuid.
As explained in the following thread, memory fence can be used instead of cpuid:
http://stackoverflow.com/a/12634857
As showed in the following threads, rdtscp can also be used:
http://stackoverflow.com/a/27697754
http://dpdk.org/ml/archives/dev/2015-April/016770.html
It reminds me that we should deprecate rte_rdtsc() and rte_get_tsc_cycles() in
favor of a more generic name, e.g. rte_get_clock_cycles().
