[dpdk-dev] librte_power w/ intel_pstate cpufreq governor

[Matthew Hall <mhall@mhcomputing.net>]

Hello all,

I wanted to ask some questions about librte_power and the great adaptive 
polling / IRQ mode example in l3fwd-power.

I am very interested in getting this to work in my project because it will 
make it much friendlier to attract new community developers if I am as 
cooperative as possible with system resources.

Let's discuss the init process for a moment. It has some problems on my 
system, and I need some help to figure out how to handle this right.

1. Begins with the call to rte_power_init.

2. Attempts to init ACPI cpufreq mode.

2.1. Sets lcore cpufreq governor to userspace mode.

2.2. Function power_get_available_freqs checks lcore CPU frequencies from:

/sys/devices/system/cpu/cpuX/cpufreq/scaling_available_frequencies

2.3. This fails with (cryptic) error "POWER: ERR: File not openned". I am 
planning to write a patch for this error a bit later.

My kernel is using the intel_pstate driver, so scaling_available_frequencies 
does not exist:

http://askubuntu.com/questions/544266/why-are-missing-the-frequency-options-on-cpufreq-utils-indicator

3. When power_get_available_freqs fails, rte_power_acpi_cpufreq_init fails.

4. rte_power_init will try rte_power_kvm_vm_init. That will fail because it's 
a physical Skylake system not some kind of VM.

5. Now rte_power_init totally fails, with error "POWER: ERR: Unable to set 
Power Management Environment for lcore 0".

So, I have a couple of questions to figure out from here:

1. It seems bad to switch the governor into userspace before verifying the 
frequencies available in scaling_available_frequencies. If there are no 
frequencies available, it seems like it should not be trying to take over 
control of an effectively uncontrollable value.

2. If the governor is switched to userspace, and then no governing is done, it 
seems like the clockrate will necessarily always be wrong also because nothing 
will be configuring it anymore, neither kernel, nor failed DPDK userspace 
code, since rte_power_freq_up / down function pointers will always be NULL. Is 
this true? This seems bad if so.

It seems that the librte_power code is basically out of date, as pstate has 
been present since Sandy Bridge, which is quite old by now for network 
processing. I am not sure how to make this work right now. So far I see a 
couple options but I really don't know much about this stuff:

1) skip rte_power_init completely, and let intel_pstate handle it using HWP 
mode

2) disable intel_pstate, switch to the legacy ACPI cpufreq (but people warned 
this old driver is mostly a no-op and the CPU ignores its frequency requests).

The Internet advice says it's possible, but not a very good idea, to switch 
from the modern intel_pstate driver to the legacy ACPI mode. Reading through 
the kernel docs (below) state that it's better to use HWP (Hardware P State) 
mode:

https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt

If none of this rte_power_init stuff works, are the other CPU conservation 
measures inside the l3fwd-power example enough to work right with HWP all by 
themselves with nothing additional?

Thanks,
Matthew.