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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

28/01/2014 02:16, Sangjin Han:
> >> 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.

[...]
> Also, it seems that there is no guarantee that the TSC rate is
> identical to the CPU max clock frequency.

So you may submit a revert of the commit a46154b9c6bc
(timer: get TSC frequency from /proc/cpuinfo)

> 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.

Maybe that you can choose between these two methods with a runtime option.

> 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.

Feel free to submit a patch.

-- 
Thomas