From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Subject: Re: [PATCH 0/2] eal: notify secondaries on primary exit
Date: Thu, 18 Jun 2026 09:09:40 -0700 [thread overview]
Message-ID: <20260618090940.6853e9cb@phoenix.local> (raw)
In-Reply-To: <20260507210152.410419-1-stephen@networkplumber.org>
On Thu, 7 May 2026 13:58:35 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> Bugzilla 1942: when a primary process exits cleanly, secondary
> processes other than testpmd do not get notified. The notification
> mechanism added in 25.11 was placed in testpmd and used
> rte_mp_request_sync() with a testpmd-specific action name, so any
> non-testpmd secondary (dpdk-dumpcap, dpdk-pdump, dpdk-procinfo, or
> out-of-tree consumers) would log "Cannot find action: mp_testpmd"
> and the primary would block on the 5 second request timeout.
>
> Putting application-specific IPC actions on a broadcast request path
> is the wrong layer. Notification of primary exit is something every
> secondary needs and should come from EAL, not from each application.
>
> Patch 1 reverts the testpmd-side mechanism (commit f96273c8e9d3).
> The secondary-side primary alive monitor (enable_primary_monitor)
> is preserved and continues to handle detection of primary exit via
> the existing alarm-based polling of rte_eal_primary_proc_alive().
>
> Patch 2 adds a generic EAL-level notification. On primary cleanup,
> rte_mp_channel_cleanup() broadcasts an MP_REQ_QUIT message to all
> known secondaries via rte_mp_sendmsg(). Secondaries register an
> internal action handler that tears down their own MP channel on
> receipt. No new public API; no application changes required for
> any secondary, in-tree or out.
>
> This is the minimum fix suitable for backport to 25.11 stable.
> It addresses the clean exit case. The crash case (primary killed
> or signaled) continues to be handled by the existing
> rte_eal_primary_proc_alive() polling on the secondary side, which
> detects the primary's release of the config file lock.
>
> A more complete solution using a connected socket type (SOCK_SEQPACKET)
> is planned since that can handle both planned and forced exiting
> of the primary.
>
> Tested with testpmd (primary) and dpdk-dumpcap, dpdk-pdump,
> dpdk-procinfo (secondaries).
>
>
> Stephen Hemminger (2):
> Revert "app/testpmd: stop forwarding in secondary process"
> eal: notify secondary on primary exit
>
> app/test-pmd/testpmd.c | 103 ++-----------------------------
> lib/eal/common/eal_common_proc.c | 51 ++++++++++++++-
> 2 files changed, 53 insertions(+), 101 deletions(-)
>
This is a real bug fix. Even if AI is being overly wordy in describing
it; what it does is move the notification from being testpmd -> testpmd only
to a more general primary -> secondary mechanism.
Without it can demonstrate the bug rather trivially with packet
capture tools (pdump or dumpcap)
Could this get reviewed?
prev parent reply other threads:[~2026-06-18 16:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 20:58 [PATCH 0/2] eal: notify secondaries on primary exit Stephen Hemminger
2026-05-07 20:58 ` [PATCH 1/2] Revert "app/testpmd: stop forwarding in secondary process" Stephen Hemminger
2026-05-07 20:58 ` [PATCH 2/2] eal: notify secondary on primary exit Stephen Hemminger
2026-06-18 16:09 ` 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=20260618090940.6853e9cb@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.