From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: [dpdk-dev] Should we disallow running secondaries after primary has died?
Date: Fri, 26 Jul 2019 10:05:02 +0100 [thread overview]
Message-ID: <29cf5458-8459-0187-13b1-44277283fc93@intel.com> (raw)
Hi all,
While investigating this bug:
https://bugs.dpdk.org/show_bug.cgi?id=284
I came across a realization that, when primary process dies, very little
actually works. There are some documented issues that are already
present when secondary processes keep running, like memory map becoming
static, and hotplug not working any more.
What is less known (and documented) is that VFIO also completely stops
working when initializing processes, because some time since 18.xx
releases, we've fixed a long standing VFIO-related bug that had to do
with creating new containers every time a secondary is run - secondary
processes will now reuse the primary process's container instead.
Meaning, for VFIO devices, secondary process *initialization* will fail
after primary process has died, because there is no longer a process
from which we can get the VFIO container from. Things will still sort-of
work with igb_uio or in vfio-noiommu mode, but again - no memory map
updates, no hotplug, potentially other things that i don't even know about.
Therefore, while ideally we would like people to have primary process
always running, the least we can do to avoid documenting a complex
matrix of "what is supported in which case" is to disallow secondary
process initialization after primary process has died.
("disallow" as in "explicitly document it as unsupported", although we
can also outright prevent it if we want - rte_eal_primary_proc_alive()
will tell us that)
Thoughts?
--
Thanks,
Anatoly
next reply other threads:[~2019-07-26 9:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 9:05 Burakov, Anatoly [this message]
2019-07-26 9:39 ` Bruce Richardson
2019-07-26 9:50 ` Ananyev, Konstantin
2019-07-26 9:53 ` Burakov, Anatoly
2019-07-26 15:01 ` Stephen Hemminger
2019-07-26 15:44 ` Burakov, Anatoly
2019-07-26 15:56 ` Lipiec, Herakliusz
2019-07-26 16:02 ` Burakov, Anatoly
2019-07-26 16:44 ` Lipiec, Herakliusz
2019-07-26 16:57 ` Burakov, Anatoly
2019-07-26 17:33 ` Lipiec, Herakliusz
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=29cf5458-8459-0187-13b1-44277283fc93@intel.com \
--to=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=thomas@monjalon.net \
/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).