From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter02.viettel.com.vn (mailfilter02.viettel.com.vn [125.235.240.54]) by dpdk.org (Postfix) with ESMTP id 9895F1041 for ; Mon, 5 Mar 2018 13:23:38 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.47,426,1515430800"; d="scan'208";a="74295950" Received: from 125.235.240.44.adsl.viettel.vn (HELO mta1.viettel.com.vn) ([125.235.240.44]) by mailfilter02.viettel.com.vn with ESMTP; 05 Mar 2018 19:23:35 +0700 Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 431986140E8; Mon, 5 Mar 2018 19:23:25 +0700 (ICT) Received: from mta1.viettel.com.vn ([127.0.0.1]) by localhost (mta1.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id urMZBifEucBP; Mon, 5 Mar 2018 19:23:25 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 1EA596140C3; Mon, 5 Mar 2018 19:23:25 +0700 (ICT) X-Virus-Scanned: amavisd-new at Received: from mta1.viettel.com.vn ([127.0.0.1]) by localhost (mta1.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bPeFiFYq2KfD; Mon, 5 Mar 2018 19:23:25 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta1.viettel.com.vn (Postfix) with ESMTPSA id E0C9E6140D9; Mon, 5 Mar 2018 19:23:24 +0700 (ICT) To: , References: <000201d3b1f7$4b622cc0$e2268640$@viettel.com.vn> <000901d3b1f7$8b2f55d0$a18e0170$@viettel.com.vn> <001a01d3b470$0f015a00$2d040e00$@viettel.com.vn> <0f17897c-590d-d405-6ae9-e79c62b0ba43@intel.com> In-Reply-To: <0f17897c-590d-d405-6ae9-e79c62b0ba43@intel.com> Message-ID: <001d01d3b47d$56ac4b00$0404e100$@viettel.com.vn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHjgAqVf5F3cl25Xvi1mNsTtZwa8QGXrtMuAugpBlcB+0VS6wEoxojmo2TXZqA= Content-Language: en-us MilterAction: FORWARD Date: Mon, 5 Mar 2018 19:23:25 +0700 (ICT) From: longtb5@viettel.com.vn 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: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 12:23:39 -0000 Hi Dave, Unfortunately I do not have access to our server BIOS settings. The = power management task for our appliance is also on pending. I'm = expecting to return to this task in April. Maybe we can still work out a = patch before 18.05 (not sure about DPDK roadmap). Regards, -BL=20 > -----Original Message----- > From: david.hunt@intel.com [mailto:david.hunt@intel.com] > Sent: Monday, March 5, 2018 6:26 PM > To: longtb5@viettel.com.vn; dev@dpdk.org > Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor >=20 >=20 > Hi BL, >=20 >=20 > On 5/3/2018 10:48 AM, longtb5@viettel.com.vn > wrote: >=20 >=20 > Hi Dave, >=20 > Actually in my test lab which is a HP box running CentOS 7 on kernel > version > 3.10.0-693.5.2.el7.x86_64, the default cpufreq driver is pcc_cpufreq. > So I guess > disabling intel_pstate wouldn't help in my case. >=20 > # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver > pcc-cpufreq >=20 > # cat > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors > conservative userspace powersave ondemand performance >=20 > According to kernel doc, pcc_cpufreq also doesn't export > scaling_availabe_frequencies > in sysfs. >=20 > From kernel doc: > "scaling_available_frequencies is not created in /sys. No = intermediate > frequencies need to be listed because the BIOS will try to achieve = any > frequency, within limits, requested by the governor. A frequency > does not have > to be strictly associated with a P-state." >=20 > The lack of scaling_availabe_frequencies makes > power_acpi_cpufreq_init() > complains, similar to the problem with intel_pstate as in the other > thread. > I have tried (though with not much effort) to force the kernel > to use acpi-cpufreq instead but without success. >=20 > Luckily, as quoted above pcc_cpufreq supports setting of arbitrary > frequency, > so a simple workaround for now is to fake a > scaling_available_frequencies file > in another directory, then edit the code in librte_power to use that > file instead. >=20 > Regards, > -BL >=20 >=20 > -----Original Message----- > From: david.hunt@intel.com > [mailto:david.hunt@intel.com] > Sent: Monday, March 5, 2018 5:16 PM > To: longtb5@viettel.com.vn > ; dev@dpdk.org > Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq > governor >=20 > Hi BL, >=20 > I have always used "intel_pstate=3Ddisable" in my kernel > parameters at boot so > as to disable the intel_pstate driver, and force the kernel to > use the acpi- > cpufreq driver: >=20 > # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver > acpi-cpufreq >=20 > This then gives me the following options for the governor: > ['conservative', 'ondemand', 'userspace', 'powersave', > 'performance', > 'schedutil'] >=20 > Because DPDK threads typically poll, they appear as 100% > busy to the p_state > driver, so if you want to be able to change core frequency > down (as in l3fwd- > power), you need to use the acpi-cpufreq driver. >=20 > I had a read through the docs just now, and this does not > seem to be > mentioned, so I'll do up a patch to give some information on > the correct > kernel parameters to use when using the power library. >=20 > Regards, > Dave. >=20 > On 2/3/2018 7:20 AM, longtb5@viettel.com.vn > wrote: >=20 > Forgot to link the original thread. >=20 > http://dpdk.org/ml/archives/dev/2016- > January/030930.html >=20 > -BL >=20 >=20 > -----Original Message----- > From: longtb5@viettel.com.vn > [mailto:longtb5@viettel.com.vn] > Sent: Friday, March 2, 2018 2:19 PM > To: dev@dpdk.org > Cc: david.hunt@intel.com > ; mhall@mhcomputing.net > ; > helin.zhang@intel.com > ; longtb5@viettel.com.vn > > Subject: librte_power w/ intel_pstate cpufreq > governor >=20 > Hi everybody, >=20 > I know this thread was from over 2 years ago > but I ran into the same >=20 > problem >=20 > with l3fwd-power today. >=20 > Any updates on this? >=20 > -BL >=20 >=20 >=20 >=20 >=20 >=20 > Good to hear you found a workaround. >=20 > So the issue really is "Getting the Power Library working with the = ppc-cpufreq > kernel driver" :) >=20 > From wiki.archlinux.org: > ppc-cpufreq: his driver supports Processor Clocking Control interface = by > Hewlett-Packard and Microsoft Corporation which is useful on some = ProLiant > servers. >=20 > In the following doc: https://www.kernel.org/doc/Documentation/cpu- > freq/pcc-cpufreq.txt > it mentions - "When PCC mode is enabled, the platform will not expose > processor performance or throttle states (_PSS, _TSS and related ACPI > objects) to OSPM. Therefore,the native P-state driver (such as = acpi-cpufreq > for Intel, powernow-k8 forAMD) will not load". > Is there a way to disable PPC mode in the BIOS on that server? From = that > wording, it seems to imply imply that there is a way to disable PPC = (seeing that > it can be enabled). >=20 > If you can't disbale PPC, I would suggest that a patch may be needed = to allow > the power library detect if it's using acpi or ppc, and obtain a list = of cpu > frequencies accordingly. However, I don't have any HP servers = available to > me, so I'm currently unable to research a method of getting a list of = valid cpu > frequencies on a machine using the ppc driver. >=20 > If you come up with a snippet of code for listing available = frequencies on that > server, let me know and we can look at adding that into the power = library. :) >=20 > Regards, > Dave. >=20 >=20 >=20 >=20