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
