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 741EB45CE9; Mon, 11 Nov 2024 14:04:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C7CB41101; Mon, 11 Nov 2024 14:04:31 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 9974040E0C for ; Mon, 11 Nov 2024 14:03:56 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Xn8n64CZBzkWq1; Mon, 11 Nov 2024 21:01:14 +0800 (CST) Received: from dggemv704-chm.china.huawei.com (unknown [10.3.19.47]) by mail.maildlp.com (Postfix) with ESMTPS id CD3DD140134; Mon, 11 Nov 2024 21:03:53 +0800 (CST) Received: from kwepemn100009.china.huawei.com (7.202.194.112) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 11 Nov 2024 21:03:53 +0800 Received: from localhost.localdomain (10.28.79.22) by kwepemn100009.china.huawei.com (7.202.194.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 11 Nov 2024 21:03:52 +0800 From: Huisong Li To: CC: , , , , , , , Subject: [PATCH] power: fix a typo in the PM QoS guide Date: Mon, 11 Nov 2024 20:52:49 +0800 Message-ID: <20241111125249.9824-1-lihuisong@huawei.com> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.28.79.22] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemn100009.china.huawei.com (7.202.194.112) 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 The typo in the guide is hard to understand. Necessary to fix it. Fixes: dd6fd75bf662 ("power: introduce PM QoS API on CPU wide") Signed-off-by: Huisong Li --- doc/guides/prog_guide/power_man.rst | 2 +- lib/power/rte_power_qos.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/prog_guide/power_man.rst b/doc/guides/prog_guide/power_man.rst index 22e6e4fe1d..024670a9b4 100644 --- a/doc/guides/prog_guide/power_man.rst +++ b/doc/guides/prog_guide/power_man.rst @@ -118,7 +118,7 @@ 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 services are latency sensitive and very except the low resume time, +Some services are latency sensitive and request the low resume time, like interrupt packet receiving mode. Applications can set and get the CPU resume latency with diff --git a/lib/power/rte_power_qos.h b/lib/power/rte_power_qos.h index 7a8dab9272..a6d3677409 100644 --- a/lib/power/rte_power_qos.h +++ b/lib/power/rte_power_qos.h @@ -24,7 +24,7 @@ extern "C" { * https://www.kernel.org/doc/html/latest/admin-guide/abi-testing.html?highlight=pm_qos_resume_latency_us#abi-sys-devices-power-pm-qos-resume-latency-us * * 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 + * longer the resume time. Some service are delay sensitive and request the * low resume time, like interrupt packet receiving mode. * * In these case, per-CPU PM QoS API can be used to control this CPU's idle -- 2.22.0