From: Stephen Hemminger <stephen@networkplumber.org>
To: Serhii Iliushyk <sil-plv@napatech.com>
Cc: dev@dpdk.org, mko-plv@napatech.com, ckm@napatech.com
Subject: Re: [PATCH v1 0/7] migrate threads to DPDK service framework
Date: Mon, 8 Sep 2025 13:08:09 -0700 [thread overview]
Message-ID: <20250908130809.2266b0d3@hermes.local> (raw)
In-Reply-To: <20250908110446.1071964-1-sil-plv@napatech.com>
On Mon, 8 Sep 2025 13:04:38 +0200
Serhii Iliushyk <sil-plv@napatech.com> wrote:
> This modification provides better resource (CPU) management for NTNIC PMD.
>
> The following threads are migrated:
> * FLM update thread
> * Statistic thread
> * Port event thread
> * Adapter monitoring thread
> Additionally, a warning is added to inform users about the importance of
> dedicating lcores to the DPDK service framework when using the NTNIC PMD.
> The code is also cleaned up to use pthreads and rte_thread APIs.
>
> After this patch series, an each application using NTNIC PMD should
> dedicate at least five(5) cores for DPDK service framework to ensure
> proper operation of the NTNIC PMD.
I was concerned with excessive control thread usage before, and this
seems to be worse not better.
There are conflicting use cases here:
1. The original DPDK goal was to make effective use of multiple cores
with no locking. Intel customers often had idle lcore's and some CPU's
had lots of inactive lcores that could be used to get more work done.
Dedicating some to service tasks etc was a natural outcome.
2. DPDK applications (OVS, Grout, VPP) usually want to know about lcores
at least in the documentation and examples. They don't cover the case
of service lcores.
3. Dedicated low core count smart NIC's using DPDK. In this case it
makes sense to be frugal with lcores since the point of the smart NIC
is to be able to run other control services. For example, the MS
NIC had hard limit on the DPDK part (via cgroups) of only 4 + main
lcores.
Granted NTNIC is likely only being used for a specific application on
a specific set of hardware.
The ideal would be to have better control event management in EAL.
Something like "libevent" style API. This would reduce control core
needs, and avoid any potential resource conflict overlap between control
threads.
prev parent reply other threads:[~2025-09-08 20:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 11:04 Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 1/7] net/ntnic: introduce service API for NTNIC PMD Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 2/7] net/ntnic: migrate flm update thread to service Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 3/7] net/ntnic: migrate statistic " Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 4/7] net/ntnic: migrate port event " Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 5/7] net/ntnic: migrate adapter mon " Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 6/7] net/ntnic: add warning about service cores Serhii Iliushyk
2025-09-08 11:04 ` [PATCH v1 7/7] net/ntnic: cleanup using pthreads and rte_thread Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 0/7] migrate threads to DPDK service framework Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 1/7] net/ntnic: introduce service API for NTNIC PMD Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 2/7] net/ntnic: migrate flm update thread to service Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 3/7] net/ntnic: migrate statistic " Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 4/7] net/ntnic: migrate port event " Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 5/7] net/ntnic: migrate adapter mon " Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 6/7] net/ntnic: add warning about service cores Serhii Iliushyk
2025-09-08 14:17 ` [PATCH v2 7/7] net/ntnic: cleanup using pthreads and rte_thread Serhii Iliushyk
2025-09-08 20:08 ` 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=20250908130809.2266b0d3@hermes.local \
--to=stephen@networkplumber.org \
--cc=ckm@napatech.com \
--cc=dev@dpdk.org \
--cc=mko-plv@napatech.com \
--cc=sil-plv@napatech.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).