From: Stephen Hemminger <stephen@networkplumber.org>
To: 郭春霞 <cx.guo@samsung.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, 张士亚 <sy0705.zhang@samsung.com>,
金明 <ming83.jin@samsung.com>,
"SRC-B Security" <bstsecurity@samsung.com>
Subject: Re: Inquiry About DPDK's Roadmap for Dynamic CPU Scaling Support
Date: Tue, 8 Apr 2025 06:27:28 -0700 [thread overview]
Message-ID: <20250408062728.013a5b61@hermes.local> (raw)
In-Reply-To: <20250328033731epcms5p1393d177ee4de90debad11e9578e758f9@epcms5p1>
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.
prev parent reply other threads:[~2025-04-08 13:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250328033731epcms5p1393d177ee4de90debad11e9578e758f9@epcms5p1>
2025-03-28 3:37 ` 郭春霞
2025-04-08 13:27 ` Stephen Hemminger [this message]
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=20250408062728.013a5b61@hermes.local \
--to=stephen@networkplumber.org \
--cc=bstsecurity@samsung.com \
--cc=cx.guo@samsung.com \
--cc=dev@dpdk.org \
--cc=ming83.jin@samsung.com \
--cc=sy0705.zhang@samsung.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;
as well as URLs for NNTP newsgroup(s).