From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DE83643D56; Tue, 26 Mar 2024 17:04:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5FA384029F; Tue, 26 Mar 2024 17:04:58 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 866F64013F for ; Tue, 26 Mar 2024 17:04:56 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id CAB6820B915A; Tue, 26 Mar 2024 09:04:55 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com CAB6820B915A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1711469095; bh=TOPxnYNVNibVOY0T2NWJ5nAUWcaAoCxdvJ7f1pq6yF8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S46xvC3XL/zX978i/ckOdw20ic7Xom90n8L6q9IHxodSUaBwvJHqCbyPwiN2Ds428 ON85SclKD7SjIgMFj2M3w63jxrhmwwxwggVfa/pV1IfVQ0QW8Qi3md8b6yhxqK6XmY RxPI1LdyarD/YzoVX/vFFs2oUAveIYIr7engs+UA= Date: Tue, 26 Mar 2024 09:04:55 -0700 From: Tyler Retzlaff To: "lihuisong (C)" Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, weh@microsoft.com, "longli@microsoft.com >> Long Li" , alan.elder@microsoft.com, thomas@monjalon.net, ferruh.yigit@amd.com, anatoly.burakov@intel.com, david.hunt@intel.com, sivaprasad.tummala@amd.com, liuyonglong@huawei.com Subject: Re: [PATCH 0/2] introduce PM QoS interface Message-ID: <20240326160455.GA20977@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240320105529.5626-1-lihuisong@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F315@smartserver.smartshare.dk> <9d896d8e-e624-6501-5c2d-d6b664c9a15d@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F31C@smartserver.smartshare.dk> <9e85c849-99d9-2d81-b79f-28fc49a54e4f@huawei.com> <20240322175547.GB11150@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <78a24f93-0c11-04ca-0df0-f60ed466092a@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78a24f93-0c11-04ca-0df0-f60ed466092a@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Mar 26, 2024 at 10:20:45AM +0800, lihuisong (C) wrote: > Hi Tyler, > > 在 2024/3/23 1:55, Tyler Retzlaff 写道: > >On Fri, Mar 22, 2024 at 04:54:01PM +0800, lihuisong (C) wrote: > >>+Tyler, +Alan, +Wei, +Long for asking this similar feature on Windows. > >> > >>在 2024/3/21 21:30, Morten Brørup 写道: > >>>>From: lihuisong (C) [mailto:lihuisong@huawei.com] > >>>>Sent: Thursday, 21 March 2024 04.04 > >>>> > >>>>Hi Moren, > >>>> > >>>>Thanks for your revew. > >>>> > >>>>在 2024/3/20 22:05, Morten Brørup 写道: > >>>>>>From: Huisong Li [mailto:lihuisong@huawei.com] > >>>>>>Sent: Wednesday, 20 March 2024 11.55 > >>>>>> > >>>>>>The system-wide CPU latency QoS limit has a positive impact on the idle > >>>>>>state selection in cpuidle governor. > >>>>>> > >>>>>>Linux creates a cpu_dma_latency device under '/dev' directory to obtain the > >>>>>>CPU latency QoS limit on system and send the QoS request for userspace. > >>>>>>Please see the PM QoS framework in the following link: > >>>>>>https://docs.kernel.org/power/pm_qos_interface.html?highlight=qos > >>>>>>This feature is supported by kernel-v2.6.25. > >>>>>> > >>>>>>The deeper the idle state, the lower the power consumption, but the longer > >>>>>>the resume time. Some service are delay sensitive and very except the low > >>>>>>resume time, like interrupt packet receiving mode. > >>>>>> > >>>>>>So this series introduce PM QoS interface. > >>>>>This looks like a 1:1 wrapper for a Linux kernel feature. > >>>>right > >>>>>Does Windows or BSD offer something similar? > >>>>How do we know Windows or BSD support this similar feature? > >>>Ask Windows experts or research using Google. > >>I download freebsd source code, I didn't find this similar feature. > >>They don't even support cpuidle feature(this QoS feature affects cpuilde.). > >>I don't find any useful about this on Windows from google. > >> > >> > >>@Tyler, @Alan, @Wei and @Long > >> > >>Do you know windows support that userspace read and send CPU latency > >>which has an impact on deep level of CPU idle? > >it is unlikely you'll find an api that let's you manage things in terms > >of raw latency values as the linux knobs here do. windows more often employs > >policy centric schemes to permit the system to abstract implementation detail. > > > >powercfg is probably the closest thing you can use to tune the same > >things on windows. where you select e.g. the 'performance' scheme but it > >won't allow you to pick specific latency numbers. > > > >https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/powercfg-command-line-options > > Thanks for your feedback. I will take a look at this tool. > > > > >>>>The DPDK power lib just work on Linux according to the meson.build under > >>>>lib/power. > >>>>If they support this features, they can open it. > >>>The DPDK power lib currently only works on Linux, yes. > >>>But its API should still be designed to be platform agnostic, so the functions can be implemented on other platforms in the future. > >>> > >>>DPDK is on track to work across multiple platforms, including Windows. > >>>We must always consider other platforms, and not design DPDK APIs as if they are for Linux/BSD only. > >>totally understand you. > >since lib/power isn't built for windows at this time i don't think it's > >appropriate to constrain your innovation. i do appreciate the engagement > >though and would just offer general guidance that if you can design your > >api with some kind of abstraction in mind that would be great and by all > >means if you can figure out how to wrangle powercfg /Qh into satisfying the > >api in a policy centric way it might be kind of nice. > Testing this by using powercfg on Windows creates a very challenge for me. > So I don't plan to do this on Windows. If you need, you can add it, ok? ordinarily i would say it is appropriate to, however in this circumstance i agree. there is quite possibly significant porting work to be done so i would have to address it if we ever include it for windows. thanks > > > >i'll let other windows experts chime in here if they choose. > > > >thanks! > > > >>>>>Furthermore, any high-res timing should use nanoseconds, not microseconds or > >>>>milliseconds. > >>>>>I realize that the Linux kernel only uses microseconds for these APIs, but > >>>>the DPDK API should use nanoseconds. > >>>>Nanoseconds is more precise, it's good. > >>>>But DPDK API how use nanoseconds as you said the the Linux kernel only > >>>>uses microseconds for these APIs. > >>>>Kernel interface just know an integer value with microseconds unit. > >>>One solution is to expose nanoseconds in the DPDK API, and in the Linux specific implementation convert from/to microseconds. > >>If so, we have to modify the implementation interface on Linux. This > >>change the input/output unit about the interface. > >>And DPDK also has to do this based on kernel version. It is not good. > >>The cpuidle governor select which idle state based on the worst-case > >>latency of idle state. > >>These the worst-case latency of Cstate reported by ACPI table is in > >>microseconds as the section 8.4.1.1. _CST (C States) and 8.4.3.3. > >>_LPI (Low Power Idle States) in ACPI spec [1]. > >>So it is probably not meaning to change this interface implementation. > >> > >>For the case need PM QoS in DPDK, I think, it is better to set cpu > >>latency to zero to prevent service thread from the deeper the idle > >>state. > >>>You might also want to add a note to the in-line documentation of the relevant functions that the Linux implementation only uses microsecond resolution. > >>> > >>[1] https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html > >.