DPDK patches and discussions
 help / color / mirror / Atom feed
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

             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).