[dpdk-dev] set_tsc_freq() wrong return value - bug?

[Matteo Lanzuisi <m.lanzuisi@resi.it>]

Hi all,

during some tests with dpdk 18.02.2 on RedHat 7 kernel 
3.10.0-862.el7.x86_64 using Intel X710 and 2 x Intel(R) Xeon(R) Gold 
6130 CPU @ 2.10GHz I found the following.

I put some log in the function set_tsc_freq as you can see below

void
set_tsc_freq(void)
{
         uint64_t freq;

         freq = get_tsc_freq_arch();
         RTE_LOG(WARNING, EAL, "Function get_tsc_freq_arch() returns 
%lu\n", freq);
         if (!freq)
         {
                 freq = get_tsc_freq();
                 RTE_LOG(WARNING, EAL, "Function get_tsc_freq() returns 
%lu\n", freq);
         }
         if (!freq)
         {
                 freq = estimate_tsc_freq();
                 RTE_LOG(WARNING, EAL, "Function estimate_tsc_freq() 
returns %lu\n", freq);
         }
         RTE_LOG(DEBUG, EAL, "TSC frequency is ~%" PRIu64 " KHz\n", freq 
/ 1000);
         eal_tsc_resolution_hz = freq;
}

the output of this function is:

"EAL: Function get_tsc_freq_arch() returns 2100000000"

but with this value if I use the rte_get_timer_cycles() in my 
application and try to convert the return value into seconds I saw that 
the more time passes the more date is wrong.

Moreover, if I comment some rows in the set_tsc_freq function this way

void
set_tsc_freq(void)
{
         uint64_t freq;

         //freq = get_tsc_freq_arch();
         //RTE_LOG(WARNING, EAL, "Function get_tsc_freq_arch() returns 
%lu\n", freq);
         //if (!freq)
         //{
                 freq = get_tsc_freq();
                 RTE_LOG(WARNING, EAL, "Function get_tsc_freq() returns 
%lu\n", freq);
         //}
         if (!freq)
         {
                 freq = estimate_tsc_freq();
                 RTE_LOG(WARNING, EAL, "Function estimate_tsc_freq() 
returns %lu\n", freq);
         }
         RTE_LOG(DEBUG, EAL, "TSC frequency is ~%" PRIu64 " KHz\n", freq 
/ 1000);
         eal_tsc_resolution_hz = freq;
}

the result is

"EAL: Function get_tsc_freq() returns 2094994596"

with this value the conversion into seconds from rte_get_timer_cycles() 
is always correct.

Is this a bug? Or am I doing something wrong?

Regards,
Matteo