DPDK usage discussions
 help / color / mirror / Atom feed
From: Mikhail Malofeev <mdmalofeev@gmail.com>
To: users@dpdk.org
Subject: DPDK multiprocessing issue: what if primary process dies
Date: Mon, 10 Mar 2025 17:29:09 +0100	[thread overview]
Message-ID: <CAF6DLt681eC8J-EUFCKJsTOVpSG0naO24NSvA1CO0_Y6fbvw4w@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

Hello everyone,

I am new to DPDK and I am implementing a DPDK-based application which might
be running as a multi-process application. My understanding is that one of
the processes should be the primary one, responsible for initializing and
managing the hugepages. All the other processes should be secondary,
meaning that they are connected to the primary process during DPDK
initialization to get information about hugepages (please correct me if I
am mistaken here).

I am interested in the scenario where there are multiple DPDK processes,
and the primary process dies. As far as I understand, existing secondary
processes will continue running; however, I will not be able to start new
DPDK processes:
1) I cannot start a new primary process because it will try to initialize
hugepages and this will fail since some of them are in use by existing
secondary processes (source:
https://stackoverflow.com/questions/74602244/dpdk-multi-process-kill-a-primary-process-and-restart-as-a-secondary-doesnt-wo
)
2) I cannot start a new secondary process because there is no primary
process to connect to and get the hugepages info, so the secondary process
won't be able to complete the initialization.

Hence, if my primary process terminates, what should I do in order to start
it again?

I have come up with two possible solutions:
1) If the primary process dies, I will have to kill all the secondary
processes and restart everything. This solution is not ideal because I want
to minimize the amount of time when processes are not running.
2) Have a dummy primary process that does not contain any critical business
logic and is solely responsible for DPDK initialization. Then, all the
business-critical applications must be secondary processes. If one of them
dies, I can simply restart it without interrupting other processes. This
solution sounds better than the first, but it is still not perfect as it
requires running an additional dummy process which I would prefer to avoid.

Could anyone please advise me on the idiomatic way of dealing with these
multiprocessing issues?

Thank you in advance!

Best regards,
Mikhail Malofeev

[-- Attachment #2: Type: text/html, Size: 2542 bytes --]

             reply	other threads:[~2025-03-10 16:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 16:29 Mikhail Malofeev [this message]
2025-03-10 21:24 ` Stephen Hemminger

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=CAF6DLt681eC8J-EUFCKJsTOVpSG0naO24NSvA1CO0_Y6fbvw4w@mail.gmail.com \
    --to=mdmalofeev@gmail.com \
    --cc=users@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 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).