From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3] libs/power: add p-state driver compatibility Date: Thu, 20 Dec 2018 11:44:45 +0100 Message-ID: <1719830.BVpRu4Kufa@xps> References: <1544786028-10138-1-git-send-email-liang.j.ma@intel.com> <9037763.qK0Rf51nFT@xps> <1545302540.9718.20.camel@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: "Burakov, Anatoly" , "Hunt, David" , Liang Ma , dev@dpdk.org, qian.q.xu@intel.com, ferruh.yigit@intel.com To: Luca Boccassi Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D52C41B938 for ; Thu, 20 Dec 2018 11:44:48 +0100 (CET) In-Reply-To: <1545302540.9718.20.camel@debian.org> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 20/12/2018 11:42, Luca Boccassi: > On Thu, 2018-12-20 at 11:10 +0100, Thomas Monjalon wrote: > > 20/12/2018 10:33, Burakov, Anatoly: > > > On 20-Dec-18 9:25 AM, Burakov, Anatoly wrote: > > > > On 19-Dec-18 8:31 PM, Thomas Monjalon wrote: > > > > > 19/12/2018 10:09, Hunt, David: > > > > > > On 19/12/2018 3:18 AM, Thomas Monjalon wrote: > > > > > > > 14/12/2018 14:11, Liang Ma: > > > > > > > > Previously, in order to use the power library, it was > > > > > > > > necessary > > > > > > > > for the user to disable the intel_pstate driver by adding > > > > > > > > =E2=80=9Cintel_pstate=3Ddisable=E2=80=9D to the kernel comm= and line for the > > > > > > > > system, > > > > > > > > which causes the acpi_cpufreq driver to be loaded in its > > > > > > > > place. > > > > > > > >=20 > > > > > > > > This patch adds the ability for the power library use the > > > > > > > > intel-pstate > > > > > > > > driver. > > > > > > > >=20 > > > > > > > > It adds a new suite of functions behind the current power > > > > > > > > library API, > > > > > > > > and will seamlessly set up the user facing API function > > > > > > > > pointers to > > > > > > > > the relevant functions depending on whether the system is > > > > > > > > running with > > > > > > > > acpi_cpufreq kernel driver, intel_pstate kernel driver or > > > > > > > > in a guest, > > > > > > > > using kvm. The library API and ABI is unchanged. > > > > > > > >=20 > > > > > > > > Signed-off-by: Liang Ma > > > > > > > >=20 > > > > > > > > Reviewed-by: Anatoly Burakov > > > > > > > > --- > > > > > > >=20 > > > > > > > Please write a changelog when sending a new version. > > > > > > >=20 > > > > > > > Dave, any comment on this patch? > > > > > >=20 > > > > > >=20 > > > > > > Looks good to me. > > > > > >=20 > > > > > > Acked-by: David Hunt > > > > > >=20 > > > > > >=20 > > > > > > > > --- /dev/null > > > > > > > > +++ b/lib/librte_power/power_pstate_cpufreq.c > > > > > > > > @@ -0,0 +1,770 @@ > > > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > > > > > > + * Copyright(c) 2018-2018 Intel Corporation > > > > > > >=20 > > > > > > > Something wrong here :) > > > > > >=20 > > > > > > Yes, should simply be "Copyright(c) 2018 Intel Corporation" > > > > >=20 > > > > >=20 > > > > > There is also a compilation error with meson: > > > > >=20 > > > > > lib/librte_power/rte_power_empty_poll.h:20:10: fatal error: > > > > > rte_timer.h: No such file or directory > > > >=20 > > > > That's an EAL header, and this file was not modified or > > > > referenced in=20 > > > > this commit. This sounds like a pre-existing problem (with meson=20 > > > > build-system?), not related to the patchset. > > > >=20 > > > > Is this library not built by default by our patch compilation CI? > > > >=20 > > >=20 > > > Disregard that, the patch has a bug in meson build file. > > >=20 > > > Still, why doesn't our CI build meson? > >=20 > > I think we should build a new CI for compilation testing. > > Luca proposed to use OBS. > > Luca, can we work on it? >=20 > https://build.opensuse.org/package/show/home:bluca:dpdk/dpdk >=20 > The Debian/Ubuntu builds use Meson, the Fedora/CentOS/RHEL/SUSE ones > use the makefiles. >=20 > More complexity (eg: building with both on all distros) can be added > with a bit of work, if required and if it's worth it. >=20 > A postreceive curl call can be added to trigger it on every push to > master. Emails on failure can be sent with the logs. We need to integrate it with patchwork, yes. Let's discuss it offline, thanks.