From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter01.viettel.com.vn (mailfilter01.viettel.com.vn [125.235.240.53]) by dpdk.org (Postfix) with ESMTP id 197635F34 for ; Mon, 5 Mar 2018 11:48:39 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.47,426,1515430800"; d="scan'208";a="73710881" Received: from 125.235.240.44.adsl.viettel.vn (HELO mta1.viettel.com.vn) ([125.235.240.44]) by mailfilter01.viettel.com.vn with ESMTP; 05 Mar 2018 17:48:37 +0700 Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 70ED661402E; Mon, 5 Mar 2018 17:48: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 QXNKjth-YQge; Mon, 5 Mar 2018 17:48:25 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 30EE161403B; Mon, 5 Mar 2018 17:48: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 6V584tE5yRIy; Mon, 5 Mar 2018 17:48:25 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta1.viettel.com.vn (Postfix) with ESMTPSA id 4B68961401D; Mon, 5 Mar 2018 17:48:21 +0700 (ICT) To: , References: <000201d3b1f7$4b622cc0$e2268640$@viettel.com.vn> <000901d3b1f7$8b2f55d0$a18e0170$@viettel.com.vn> In-Reply-To: Message-ID: <001a01d3b470$0f015a00$2d040e00$@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: AQHjgAqVf5F3cl25Xvi1mNsTtZwa8QGXrtMuAugpBlejfeAtcA== Content-Language: en-us MilterAction: FORWARD Date: Mon, 5 Mar 2018 17:48: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 10:48:40 -0000 Hi Dave, 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=20 disabling intel_pstate wouldn't help in my case. # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver pcc-cpufreq # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors=20 conservative userspace powersave ondemand performance According to kernel doc, pcc_cpufreq also doesn't export = scaling_availabe_frequencies in sysfs. >>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." 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. Luckily, as quoted above pcc_cpufreq supports setting of arbitrary = frequency,=20 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. Regards, -BL > -----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: > > Forgot to link the original thread. > > > > http://dpdk.org/ml/archives/dev/2016-January/030930.html > > > > -BL > > > >> -----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 > >> > >> Hi everybody, > >> > >> I know this thread was from over 2 years ago but I ran into the = same > > problem > >> with l3fwd-power today. > >> > >> Any updates on this? > >> > >> -BL > >