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.
