Re: librte_power w/ intel_pstate cpufreq governor

[Matthew Hall <mhall@mhcomputing.net>]

On Thu, Jan 14, 2016 at 07:15:51AM +0000, Zhang, Helin wrote:
> That's disappointing if Skylake is like that. Let's have a learning first, 
> and then check if we can fix that. But in addition, DPDK provide interrupt 
> based packet receiving mechanism, can it be one of your choice?

Maybe I am wrong. But I could not disprove what the Linux p_state driver 
Documentation file and other places claimed, which is that the clockrate 
control is no-opped, because the white papers on Intel HWP are not findable in 
the Intel website, or by using Google with the operator "site:intel.com".

The IRQ based part is still enabled and works quite well in a very trivial 
test so far... but the clockrate callback handlers are null and the governor 
setting gets corrupted, both due to failed init of librte_power. So I will 
have to rebuild DPDK with the librte_power ACPI + KVM init commented out and 
the fastpath clockrate callback functions commented out of course. It is minor 
so I can do it to see what will happen.

> If no objection, I will find time later (may be in a month) to investigate 
> that. Of cause, please try to investigate that from your side.

Agreed.

> That's always there, for example, DPDK can exit accidently, without caring 
> anything. Then you can have the similar issue again.

Of course, it could. But if there was some kind of shutdown function, at least 
then I could call it from the signal handler I already have which closes the 
ports (this prevents nasty port lockups on virtio-net port DMA memory zones 
which can happen on future runs otherwise).

> It seems that you are so important for Intel. :) I don't have Skylake in hand. :(

:) Hahaha... newegg.com to the rescue. I guess we need to be sure there is 
some program to test the stuff in DPDK for the new kernels and hardware. It 
appears we are pretty far behind now... I saw several threads about things 
that were behind just today.

> Regards,
> Helin

Matthew.