DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "lihuisong (C)" <lihuisong@huawei.com>
To: "Macnamara, Chris" <chris.macnamara@intel.com>,
	<anatoly.burakov@intel.com>, <sivaprasad.tummala@amd.com>
Cc: <dev@dpdk.org>, <thomas@monjalon.net>,
	<stephen@networkplumber.org>, <fengchengwen@huawei.com>,
	<yangxingui@huawei.com>, <zhanjie9@hisilicon.com>,
	 <john.mcnamara@intel.com>, <lihuisong@huawei.com>
Subject: Re: [PATCH v2 1/5] examples/l3fwd-power: fix uncore deinit for non-legacy
Date: Fri, 3 Jul 2026 12:07:04 +0800	[thread overview]
Message-ID: <64f3e01b-f8cd-4c94-9fa2-dfb3ce687bb1@huawei.com> (raw)
In-Reply-To: <6df97f76-27d7-49f2-8d23-30601c12ca0a@intel.com>

Hi Macnamara,

Thanks for your review.


On 7/2/2026 7:06 PM, Macnamara, Chris wrote:
>> Uncore resources were not being deinitialized in non-legacy modes (such
>> as pmd-mgmt), causing the uncore frequency not to return to its original
>> value after the application exited.
>>
>> The root cause is that uncore initialization can be performed for all
>> modes, whereas the deinitialization logic is incorrectly restricted
>> to legacy mode only. So do the deinitialization of uncore on all app
>> modes.
>>
>> Fixes: 10db2a5b8724 ("examples/l3fwd-power: add options for uncore 
>> frequency")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> ---
>>   examples/l3fwd-power/main.c | 66 ++++++++++++++++++++-----------------
>>   1 file changed, 35 insertions(+), 31 deletions(-)
>>
>> diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
>> index 02ec17d799..1122aeb930 100644
>> --- a/examples/l3fwd-power/main.c
>> +++ b/examples/l3fwd-power/main.c
>> @@ -2271,28 +2271,31 @@ init_power_library(void)
>>       unsigned int lcore_id;
>>       int ret = 0;
>>   -    RTE_LCORE_FOREACH(lcore_id) {
>> -        /* init power management library */
>> -        ret = rte_power_init(lcore_id);
>> -        if (ret) {
>> -            RTE_LOG(ERR, L3FWD_POWER,
>> -                "Library initialization failed on core %u\n",
>> -                lcore_id);
>> -            return ret;
>> -        }
>> -        /* we're not supporting the VM channel mode */
>> -        env = rte_power_get_env();
>> -        if (env != PM_ENV_ACPI_CPUFREQ &&
>> -                env != PM_ENV_PSTATE_CPUFREQ &&
>> -                env != PM_ENV_AMD_PSTATE_CPUFREQ &&
>> -                env != PM_ENV_CPPC_CPUFREQ) {
>> -            RTE_LOG(ERR, L3FWD_POWER,
>> -                "Only ACPI and PSTATE mode are supported\n");
>> -            return -1;
>> +    /* only legacy mode relies on the initialization of cpufreq 
>> library */
>> +    if (app_mode == APP_MODE_LEGACY) {
>> +        RTE_LCORE_FOREACH(lcore_id) {
>> +            /* init power management library */
>> +            ret = rte_power_init(lcore_id);
>> +            if (ret) {
>> +                RTE_LOG(ERR, L3FWD_POWER,
>> +                    "Library initialization failed on core %u\n",
>> +                    lcore_id);
>> +                return ret;
>> +            }
>> +            /* we're not supporting the VM channel mode */
>> +            env = rte_power_get_env();
>> +            if (env != PM_ENV_ACPI_CPUFREQ &&
>> +                    env != PM_ENV_PSTATE_CPUFREQ &&
>> +                    env != PM_ENV_AMD_PSTATE_CPUFREQ &&
>> +                    env != PM_ENV_CPPC_CPUFREQ) {
>> +                RTE_LOG(ERR, L3FWD_POWER,
>> +                    "Only ACPI and PSTATE mode are supported\n");
>> +                return -1;
>> +            }
>>           }
>>       }
>>   -    if (cpu_resume_latency != -1) {
>> +    if (app_mode == APP_MODE_LEGACY && cpu_resume_latency != -1) {
>>           RTE_LCORE_FOREACH(lcore_id) {
>>               /* Back old CPU resume latency. */
>>               ret = rte_power_qos_get_cpu_resume_latency(lcore_id);
>> @@ -2329,14 +2332,16 @@ deinit_power_library(void)
>>       unsigned int lcore_id, max_pkg, max_die, die, pkg;
>>       int ret = 0;
>>   -    RTE_LCORE_FOREACH(lcore_id) {
>> -        /* deinit power management library */
>> -        ret = rte_power_exit(lcore_id);
>> -        if (ret) {
>> -            RTE_LOG(ERR, L3FWD_POWER,
>> -                "Library deinitialization failed on core %u\n",
>> -                lcore_id);
>> -            return ret;
>> +    if (app_mode == APP_MODE_LEGACY) {
>> +        RTE_LCORE_FOREACH(lcore_id) {
>> +            /* deinit power management library */
>> +            ret = rte_power_exit(lcore_id);
>> +            if (ret) {
>> +                RTE_LOG(ERR, L3FWD_POWER,
>> +                    "Library deinitialization failed on core %u\n",
>> +                    lcore_id);
>> +                return ret;
>> +            }
>>           }
>>       }
>>   @@ -2360,7 +2365,7 @@ deinit_power_library(void)
>>           }
>>       }
>>   -    if (cpu_resume_latency != -1) {
>> +    if (app_mode == APP_MODE_LEGACY && cpu_resume_latency != -1) {
>>           RTE_LCORE_FOREACH(lcore_id) {
>>               /* Restore the original value. */
>>               rte_power_qos_set_cpu_resume_latency(lcore_id,
>
> Agree there is an issue with uncore deinit.
>
> cpu_resume_latency & init_power_library: After this patch, 
> cpu_resume_latency (for C-state PM QoS control) is gated behind 
> APP_MODE_LEGACY even though it's orthogonal to the cpufreq library, so 
> it's silently ignored in pmd-mgmt/interrupt modes. It’s used for C 
> state management which applies in other modes such as interrupt mode.
Yeah, so patch 2/5 lets PM QoS can be used for all mode.
>
> Also init_power_library() now has both its blocks legacy-guarded 
> internally, the newly-unconditional call by removing APP_MODE_LEGACY 
> to it is a no-op in non-legacy modes. This leaves the two functions 
> inconsistent: init_power_library() does nothing outside legacy mode, 
> whereas deinit_power_library() still has real work to do in every mode 
> because of the uncore cleanup.
Yes, use this method to deinitialize the uncore.
Currently, the initialization of uncore is located in the parameter 
parsing function, which lead to the inconsistent.
>
> Consider, keep the APP_MODE_LEGACY guard at the init call site as the 
> init is truly legacy only or split the uncore teardown into its own 
> deinit_uncore() so that deinit_power_library() stays strictly about 
> cpufreq.
This patch doesn't plan to change the original logical about uncore.
The initialization or deinitialization of all power libs is completed in 
the same function. It is good to user.
And patch 4/5 is doing this.

In addition, I think the initialization for power libs is a little 
scattered in usage.
I am thinking how to simply these initializations for user.
For example, fill a configuration about power then call one power_init 
ops to complete all initialization.
Anyway, the current changes being made are also beneficial for this matter.
>
>

  reply	other threads:[~2026-07-03  4:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  8:11 [PATCH v2 0/5] uncore power improvements and auto-detection Huisong Li
2026-05-26  8:11 ` [PATCH v2 1/5] examples/l3fwd-power: fix uncore deinit for non-legacy Huisong Li
2026-07-02 11:06   ` Macnamara, Chris
2026-07-03  4:07     ` lihuisong (C) [this message]
2026-05-26  8:11 ` [PATCH v2 2/5] examples/l3fwd-power: enable power QoS for all modes Huisong Li
2026-05-26  8:11 ` [PATCH v2 3/5] examples/l3fwd-power: fix uncore help and log info Huisong Li
2026-05-26  8:11 ` [PATCH v2 4/5] examples/l3fwd-power: relocate uncore initialization Huisong Li
2026-05-26  8:11 ` [PATCH v2 5/5] power: support automatic detection of uncore driver Huisong Li
2026-06-10  1:33 ` [PATCH v2 0/5] uncore power improvements and auto-detection lihuisong (C)
2026-06-29  6:23 ` lihuisong (C)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64f3e01b-f8cd-4c94-9fa2-dfb3ce687bb1@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=anatoly.burakov@intel.com \
    --cc=chris.macnamara@intel.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=john.mcnamara@intel.com \
    --cc=sivaprasad.tummala@amd.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=yangxingui@huawei.com \
    --cc=zhanjie9@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox