Hmm, that's strange. I don't know how to interpret my observations then. I have access to two platforms, one is based on Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC initialisation phase. The error frequency greatly reduces if I patch loop limit as I described earlier or if I call rte_power_init and rte_power_freq_max as Thomas suggested.
But the only way to get rid of them completely is to set performance governor. On 11/28/2013 03:01 PM, Richardson, Bruce wrote: >> It's probably due to a frequency scaling. >> The timer based is initialized when DPDK initialize and the CPU can change >> its frequency, breaking next timers. >> >> The fix is to control the CPU frequency. >> Please try this, without your patch: >> for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do >> echo performance >$g; done The right fix for applications (examples and >> testpmd included) could be to call rte_power_init(). Patches are welcomed. >> > [BR] Frequency changes should not affect timers for modern Intel CPUs. Please > see the " Intel(r) 64 and IA-32 Architectures Software Developer's Manual" > Volume 3 > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf) > , Section 17.13 for more details on this. >
