From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id 86A538E84 for ; Thu, 14 Jan 2016 08:44:24 +0100 (CET) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 07CD3214; Thu, 14 Jan 2016 02:44:23 -0500 (EST) Date: Thu, 14 Jan 2016 02:44:23 -0500 From: Matthew Hall To: "Zhang, Helin" Message-ID: <20160114074423.GB15470@mhcomputing.net> References: <20151206000839.GA23450@mhcomputing.net> <5688D2EE.5010700@mhcomputing.net> <20160114070355.GA14958@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 07:44:24 -0000 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.