Re: [dpdk-dev] "No probed ethernet devices" caused by inaccurate msec_delay()

[Sangjin Han <sangjin@eecs.berkeley.edu>]

Hi,

>> It would be nice if I can bypass set_tsc_freq_from_cpuinfo() in
>> set_tsc_freq().
>
> I think it would not solve the problem because your clock is varying and the
> TSC calibration must be updated accordingly with different values by core.

Reasonably new Intel CPUs (including Nehalem) has a constant TSC rate,
regardless of the current P/C-state (constant_tsc and nonstop_tsc
flags in /proc/cpuinfo). So TSC calibration is unnecessary even with
variable clock frequency on those CPUs.

Also, it seems that there is no guarantee that the TSC rate is
identical to the CPU max clock frequency. While it happens to be true
for Intel CPUs, this article from AMD says,
(https://lkml.org/lkml/2005/11/4/173)

"The rate of the invariant TSC is implementation-dependent and will
likely *not* be the frequency of the processor core [...]"

It would be great if someone can actually measure TSC rate on AMD
processors to verify this.

I would like to suggest two possible options:

1. If we can assume that the TSC rate always equals to the max clock
frequency, then we can use
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq instead of
/proc/cpuinfo (which reflects cpuinfo_cur_freq).

2. If we can't (AMD?), we can simply get rid of
set_tsc_freq_from_cpuinfo() and fall back to set_tsc_freq_from_clock()
or set_tsc_freq_ballback() instead. I always get reasonably good
accuracy with those two functions -- the only drawback is that it
takes 0.5 - 1 second for applications to boot up. Not sure if it is a
big deal or not, though.

---

Besides the TSC frequency, the 4ms * 10 delay in
ixgbe_reset_pipeline_82599() seems too tight. On my system, it
succeeds only after 7 (or so) iterations with correct msec_delay().
The per-iteration delay (4ms; in the kernel ixgbe driver, it is set to
be 4-8ms) and/or the number of iterations (10) should be increased, I
suppose.

Sangjin