|SUCCESS| examples/l3fwd-power: fix missing return on latency get

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163922

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-12

From: Huisong Li <lihuisong at huawei.com>
Date: Tue, 12 May 2026 09:09:00 +0800
Subject: [PATCH] examples/l3fwd-power: fix missing return on latency get

Add return value when get cpu_resume_latency failed.

Fixes: 4d23d39fd06e ("examples/l3fwd-power: add PM QoS configuration")
Cc: stable at dpdk.org

Signed-off-by: Huisong Li <lihuisong at huawei.com>

This patch addresses missing error propagation in init_power_library() when
rte_power_get_cpu_resume_latency_us() fails.

> diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
> index 02ec17d799..a7a1f675d3 100644
> --- a/examples/l3fwd-power/main.c
> +++ b/examples/l3fwd-power/main.c
> @@ -2300,6 +2300,7 @@ init_power_library(void)
>  				RTE_LOG(ERR, L3FWD_POWER,
>  					"Failed to get cpu resume latency on lcore-%u, ret=%d.\n",
>  					lcore_id, ret);
> +				return ret;
>  			}
>  			resume_latency_bk[lcore_id] = ret;

Does this code assume that rte_power_get_cpu_resume_latency_us()
consistently returns negative values for error conditions?

In the error logging above, the value is treated as an error code with
"ret=%d", but then the non-error path uses the same return value as the
actual latency stored in resume_latency_bk[lcore_id]. This pattern suggests
that negative values indicate errors while non-negative values are valid
latency measurements.

If rte_power_get_cpu_resume_latency_us() can return both positive error
codes and positive latency values, doesn't this create ambiguity? The code
after this block would incorrectly store a positive error code as a valid
latency value.

Additionally, should this error path include cleanup similar to other error
handling in init_power_library()? Looking at the broader function context,
other error paths likely call rte_power_exit() or similar cleanup before
returning. Does returning directly here leave resources allocated or power
management in an inconsistent state?