On Fri, 17 Apr 2026 10:51:48 +0800 "lihuisong (C)" <[email protected]> wrote:
> On 4/16/2026 11:48 PM, Stephen Hemminger wrote: > > On Thu, 16 Apr 2026 11:05:58 +0800 > > Huisong Li <[email protected]> wrote: > > > >> The locre ID in cpufreq power must be enabled core in application. > > Spelling error, use checkpatch next time, it runs a spell checker. > > Also run devtools/check-git-log there other issues in the commit messages. > Sorry for this. > Yeah, I used checkpatch.sh and check-git-log.sh before sent out. > But it didn't found this. I guess that because the "locre" is not a word. > >> Use rte_lcore_is_enabled to verify lcore_id. > >> > >> Fixes: 6f987b594fa6 ("power: refactor core power management") > >> Cc: [email protected] > >> > >> Signed-off-by: Huisong Li <[email protected]> > >> --- > > The rte_lcore_is_enabled() will return false for service lcores. > > Is this a bug or a feature here? > My understanding is that the ROLE_RTE core is used to tasks on data > plane and the ROLE_SERVICE core is used to periodic or control-plane tasks. > Currently, power management in DPDK is mainly processed based on > services on the data plane, like the usage in pmd_mgmt or l3fwd-power. > However, the tasks on the service cores may also occupy 100% CPU. > Therefore, power library or driver should be able to be work with these > tasks. > From this perspective, allowing the ROLE_SERVICE core to set power has > the least impact on applications in this series. > what do you think, Stephen? Service lcore's are just things doing other work. They really should not be doing non-blocking poll, that is a mistake. The service cores are intended for control path things. The power API should ignore them in general but not break if a user calls a power API from a service thread.
