[dpdk-dev] librte_power w/ intel_pstate cpufreq governor
mhall at mhcomputing.net
Thu Jan 14 08:44:23 CET 2016
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.
> 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.
More information about the dev