Re: [PATCH 2/2] timer/linux: override TSC freq if no tsc_known_freq

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Sep 24, 2024 at 08:04:00PM +0300, Isaac Boukris wrote:
> Perhaps this was a bit hastily, I got an automated failure report on
> "arm64-native-linuxapp-gcc":
> 
> https://lab.dpdk.org/results/dashboard/patchsets/31106/
> 

That might be a false positive failure. I don't see how this patch could
cause issues for a single ip reassembly test case.

> Not sure which patch caused the problem, looking at the kernel code it
> looks like 'tsc_known_freq' is only set for x86 arch, but it could be
> the other patch and maybe lowering the rounding to 10KHz is too
> aggressive, maybe better 100KHz or 1MHz.

I don't see why we can't put an #ifdef in the code to always return true on
non-x86 platforms. [Or if we don't want an #ifdef, we can always use 'if
(strcmp(RTE_ARCH,"x86_64") && strcmp(RTE_ARCH,"i686"))' :-)]

Don't really have a strong opinion on the rounding, maybe others do. [Since
you give 3 options, I'm going to suggest going for the middle one -
100KHz!]

> 
> As an alternative to 'tsc_known_freq' detection, maybe just provide an
> init parameter to set the frequency manually, along with some
> known-issue documentation.
> 
> Maybe we should just allow to specify the frequency as a parameter at init

I don't think that is a great solution, better to detect the frequency if
we can.

An interesting future enhancement would be to update DPDK to work with [1],
where we read the tsc value directly from the kernel. According to that
project, this is already available on Google production kernels, though
not generally elsewhere. For those who care about having accurate TSC values,
or faster startup times, having the extra kernel module to read the TSC
value directly might be worthwhile.

Regards,
/Bruce

[1] https://github.com/trailofbits/tsc_freq_khz