Inquiry About DPDK's Roadmap for Dynamic CPU Scaling Support

Inquiry About DPDK's Roadmap for Dynamic CPU Scaling Support

[郭春霞]

[-- Attachment #1: Type: text/html, Size: 25870 bytes --]

[-- Attachment #2: Type: image/png, Size: 15092 bytes --]

[-- Attachment #3: Type: image/png, Size: 22957 bytes --]

Re: Inquiry About DPDK's Roadmap for Dynamic CPU Scaling Support

[Stephen Hemminger]

On Fri, 28 Mar 2025 12:37:31 +0900
郭春霞 <cx.guo@samsung.com> wrote:

> Dear DPDK Team,
> 
> I hope this email finds you well. 
> 
> I'm writing to inquire about DPDK's future plans regarding dynamic CPU initialization support, particularly in Kubernetes environments where exclusive CPU Pod scaling is being enhanced.
> 
> Backgroud:
> With Kubernetes upcoming improvements to InPlacePodVerticalScaling for exclusive CPU Pods (Guaranteed QoS Pods), we have encountered a limitation when using DPDK:
> • A Pod initialized with 5 exclusive CPUs can have DPDK’s EAL successfully bind and utilize these cores.
> • However, when the Pod scales up (e.g., adding 2 new CPUs), DPDK currently lacks native mechanisms to detect and initialize the newly allocated cores. This forces us to either restart the Pod (causing service disruption) or leave additional CPUs underutilized.
> 
> Key Questions:
> • Is there an active DPDK roadmap item to support binded and initialized CPUs scaling up and down?
> • If not, would the DPDK community consider contributions in this area, especially given Kubernetes’ evolving CPU management capabilities?
> 
> We believe such functionality would significantly benefit cloud-native NFV workloads. Any guidance or references to ongoing work would be greatly appreciated.
> 
> Reference Link:
> 
>         InPlacePodVerticalScaling Enhancements for guaranteed pods: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/1287-in-place-update-pod-resources/README.md#future-enhancements
> 
>         A PR to implement guaranteed pods resize: https://github.com/kubernetes/kubernetes/pull/129719
> 
> Thank you for your time and expertise. Looking forward to your insights.

I have seen no plans for doing this. It would mostly impact the application.
One way of doing it now would be launch DPDK application with max possible CPU's and instead
of using remote_launch across all workers, be more selective.

It doesn't make sense for DPDK to grow direct access to Kubernetes API's.
But maybe the kernel API for hotplug has something.