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 D189C45B42; Tue, 15 Oct 2024 11:41:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 702BD4027C; Tue, 15 Oct 2024 11:41:44 +0200 (CEST) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id A4C44400D7 for ; Tue, 15 Oct 2024 11:41:42 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4XSTXS0lp7z1HL5Q; Tue, 15 Oct 2024 17:37:28 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id 4A5101A0171; Tue, 15 Oct 2024 17:41:40 +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.39; Tue, 15 Oct 2024 17:41:39 +0800 Message-ID: <39734c23-0f65-1bae-bb4e-2c6bf06aa97c@huawei.com> Date: Tue, 15 Oct 2024 17:41:39 +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 v10 1/2] power: introduce PM QoS API on CPU wide From: "lihuisong (C)" To: Stephen Hemminger CC: , , , , , , , , , References: <20240320105529.5626-1-lihuisong@huawei.com> <20240912023812.30885-1-lihuisong@huawei.com> <20240912023812.30885-2-lihuisong@huawei.com> <20241012181030.60d7647a@hermes.local> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) 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 Hi Stephen, Can you take a look at this reply so as to send out the next version ASAP? Thanks.😁 /Huisong 在 2024/10/14 20:19, lihuisong (C) 写道: > Hi Stephen, > > > 在 2024/10/13 9:10, Stephen Hemminger 写道: >> On Thu, 12 Sep 2024 10:38:11 +0800 >> Huisong Li wrote: >> >>> + >>> +PM QoS >>> +------ >>> + >>> +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. >>> + >>> +And the >>> "/sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us" sysfs >>> +interface is used to set and get the resume latency limit on the >>> cpuX for >>> +userspace. Each cpuidle governor in Linux select which idle state >>> to enter >>> +based on this CPU resume latency in their idle task. >>> + >>> +The per-CPU PM QoS API can be used to set and get the CPU resume >>> latency based >>> +on this sysfs. >>> + >>> +The ``rte_power_qos_set_cpu_resume_latency()`` function can control >>> the CPU's >>> +idle state selection in Linux and limit just to enter the >>> shallowest idle state >>> +to low the delay of resuming service after sleeping by setting >>> strict resume >>> +latency (zero value). >>> + >>> +The ``rte_power_qos_get_cpu_resume_latency()`` function can get the >>> resume >>> +latency on specified CPU. >>> + >> These paragraphs need some editing help. The wording is awkward, >> it uses passive voice, and does not seemed directed at a user audience. >> If you need help, a writer or AI might help clarify. > How about the following description: > --> > The "/sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us" sysfs > interface is used to set and get the resume latency limit on the cpuX for > userspace. Each cpuidle governor in Linux select which idle state to > enter > based on this CPU resume latency in their idle task. > > 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. > > The ``rte_power_qos_set_cpu_resume_latency()`` and > ``rte_power_qos_get_cpu_resume_latency()`` > can set and get the CPU resume latency based on this per-CPU sysfs. > > The ``rte_power_qos_set_cpu_resume_latency()`` can control the CPU's > idle state selection and limit to enter the shallowest idle state > to low the delay of resuming service by setting strict resume > latency (zero value) so as to get better performance. >> >> It also ends up in the section associated with Intel UnCore. >> It would be better after the Turbo Boost section. > Ack >> >> >> >>> +    ret = open_core_sysfs_file(&f, "w", >>> PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id); >>> +    if (ret != 0) { >>> +        POWER_LOG(ERR, "Failed to open >>> "PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id); >>> +        return ret; >>> +    } >> The function open_core_sysfs_file() should have been written to >> return FILE * >> and then it could have same attributes as fopen(). > Do you mean we should save this handle for directly using it to get or > set this resume latency? > If it is I understand, we cannot do it like this. Because qos driver > in Linux use the "noop_llseek()" as the .llseek API. >> >> The message should include the error reason. >> >>     if (open_core_sysfs_file(&f, "w", >> PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id)) { >>         POWER_LOG(ERR, "Failed to open " >> PM_QOS_SYSFILE_RESUME_LATENCY_US ": %s", >>             lcore_id, strerror(errno)); > Good idea.  Thanks. > >> >> .