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 5469E43D1E; Fri, 22 Mar 2024 09:54:11 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 21EC1402CB; Fri, 22 Mar 2024 09:54:11 +0100 (CET) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id C29B14003C for ; Fri, 22 Mar 2024 09:54:08 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4V1GJy6VfRz2Bgbq; Fri, 22 Mar 2024 16:51:30 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id 0416D140124; Fri, 22 Mar 2024 16:54:06 +0800 (CST) Received: from [10.67.121.59] (10.67.121.59) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 22 Mar 2024 16:54:05 +0800 Message-ID: <9e85c849-99d9-2d81-b79f-28fc49a54e4f@huawei.com> Date: Fri, 22 Mar 2024 16:54:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 0/2] introduce PM QoS interface To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , , Tyler Retzlaff , , "longli@microsoft.com >> Long Li" , CC: , , , , , References: <20240320105529.5626-1-lihuisong@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F315@smartserver.smartshare.dk> <9d896d8e-e624-6501-5c2d-d6b664c9a15d@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F31C@smartserver.smartshare.dk> From: "lihuisong (C)" In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F31C@smartserver.smartshare.dk> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600004.china.huawei.com (7.193.23.242) 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 +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? >> 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. > >>> 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