On 06/10/2022 18:32, Stephen Hemminger wrote:
On Thu,  6 Oct 2022 09:38:01 +0000
Tadhg Kearney <tadhg.kear...@intel.com> wrote:

Add API to allow uncore frequency adjustment. Uncore is a
term used by Intel to describe function of a microprocessor
that are closely connected to the core to achieve high
performance. This is done through manipulating related
uncore frequency control sysfs entries to adjust the
minimum and maximum uncore frequency values and works
on Linux for Intel hardware.

Signed-off-by: Tadhg Kearney <tadhg.kear...@intel.com>
Reviewed-by: David Hunt <david.h...@intel.com>
Acked-by: David Hunt <david.h...@intel.com>


Hi Stephen,

Looks like this is missing an opportunity for a more general
long term solution in DPDK.


We're hoping that this is the first step along the path to that long-term solution. It's like the power library frequency control for cores, which was initially Intel only, and then more architectures were added over time. The API's are experimental, so can be adapted if needed.


Shouldn't this be a general thing like the Linux kernel scheduler.

I don't think the kernel scheduler has any concept of uncore busyness, the uncore frequency is typically controlled by hardware, and if there's enough polling going on, the frequency of the uncore will remain high (if uncore frequency scaling is enabled). We're addressing that in this patch in that if the application realises that it's not processing a lot of packets even though most of it's cores are polling, it can tell the hardware to scale down the uncore to save power.


Uncore is Intel specific, but there is already big/little cores
on many ARM platforms.

I don't think big/little is related to uncore frequency scaling. The big/little cores still need to communicate via that architecture's communications bus (called uncore in Intel's case, though I've seen that term used on other architectures also). Where an architecture can scale the frequency of this communications bus, this patch set's functionality can be extended in the future to cover this.

Regards,
Dave


Reply via email to