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 0377345B53; Thu, 17 Oct 2024 04:25:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B99C24021F; Thu, 17 Oct 2024 04:25:09 +0200 (CEST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id 38B2340144 for ; Thu, 17 Oct 2024 04:25:08 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4XTWqC14T4z2DdFN; Thu, 17 Oct 2024 10:23:51 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id 31E12140138; Thu, 17 Oct 2024 10:25: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.39; Thu, 17 Oct 2024 10:25:05 +0800 Message-ID: Date: Thu, 17 Oct 2024 10:25:04 +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 2/2] examples/l3fwd-power: add PM QoS configuration To: Konstantin Ananyev , "dev@dpdk.org" CC: "mb@smartsharesystems.com" , "thomas@monjalon.net" , "ferruh.yigit@amd.com" , "anatoly.burakov@intel.com" , "david.hunt@intel.com" , "sivaprasad.tummala@amd.com" , "stephen@networkplumber.org" , "david.marchand@redhat.com" , Fengchengwen , liuyonglong References: <20240320105529.5626-1-lihuisong@huawei.com> <20240912023812.30885-1-lihuisong@huawei.com> <20240912023812.30885-3-lihuisong@huawei.com> <730159b83622413f9f0ed77b78a96323@huawei.com> <1b2a3bc1-49ac-a0cf-cc32-0ae4ba71adb4@huawei.com> <979edbe7eb4044c898f2a63bda781690@huawei.com> From: "lihuisong (C)" In-Reply-To: <979edbe7eb4044c898f2a63bda781690@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) 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 在 2024/10/16 8:24, Konstantin Ananyev 写道: > >>>> Add PM QoS configuration to declease the delay after sleep in case of >>>> entering deeper idle state. >>>> >>>> Signed-off-by: Huisong Li >>>> Acked-by: Morten Brørup >>>> --- >>>> examples/l3fwd-power/main.c | 24 ++++++++++++++++++++++++ >>>> 1 file changed, 24 insertions(+) >>>> >>>> diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c >>>> index 2bb6b092c3..b0ddb54ee2 100644 >>>> --- a/examples/l3fwd-power/main.c >>>> +++ b/examples/l3fwd-power/main.c >>>> @@ -47,6 +47,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include "perf_core.h" >>>> #include "main.h" >>>> @@ -2260,6 +2261,22 @@ init_power_library(void) >>>> return -1; >>>> } >>>> } >>>> + >>>> + RTE_LCORE_FOREACH(lcore_id) { >>>> + /* >>>> + * Set the worker lcore's to have strict latency limit to allow >>>> + * the CPU to enter the shallowest idle state. >>>> + */ >>>> + ret = rte_power_qos_set_cpu_resume_latency(lcore_id, >>>> + RTE_POWER_QOS_STRICT_LATENCY_VALUE); >>> I wonder why it is set to all worker cores silently and unconditionally? >>> Wouldn't it be a change from current behavior of the power library? >> L3fwd-power uses Rx interrupt to receive packet. > AFAIK, not exactly. > From what I remember l3fwd-power still runs RX in poll mode, > thought it counts number of idle rx bursts. > As that number goes above some threshold, it puts itself into > sleep with some timeout value. Exactly. > >> Do you mean this >> setting should be for the core of Rx queue, right? >> This setting doesn't change the behavior of l3fwd-power. It is just for >> getting low resume latency when worker core wakes up from sleeping. > As understand your patch - you force CPU to select more shallow C state > when entering such sleep. > Then it means that possible packet loss will be smaller, > but power consumption probably higher, correct? correct. > If so, then it looks like a change from current behavior for that app, > and we probably need to document what will be an expected change. > Or probably as a better way - provider user with a way to choose, > new cmdline option or so. Yes. The power consumption may increase but the performance is better due to this patch if the platform enables cpuidle funtion. After all, this is just a very little point. It is enough to document this change or impact in doc of this API. Just let it more clear for user. What do you think? > > >>>> + if (ret != 0) { >>>> + RTE_LOG(ERR, L3FWD_POWER, >>>> + "Failed to set strict resume latency on core%u.\n", >>>> + lcore_id); >>>> + return ret; >>>> + } >>>> + } >>>> + >>>> return ret; >>>> } >>>> >>>> @@ -2299,6 +2316,13 @@ deinit_power_library(void) >>>> } >>>> } >>>> } >>>> + >>>> + RTE_LCORE_FOREACH(lcore_id) { >>>> + /* Restore the original value in kernel. */ >>>> + rte_power_qos_set_cpu_resume_latency(lcore_id, >>>> + RTE_POWER_QOS_RESUME_LATENCY_NO_CONSTRAINT); >>>> + } >>>> + >>>> return ret; >>>> } >>>> >>>> -- >>>> 2.22.0