From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 97CBEA046B for ; Fri, 26 Jul 2019 11:39:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 728991C409; Fri, 26 Jul 2019 11:39:58 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B33EF1C408 for ; Fri, 26 Jul 2019 11:39:56 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 02:39:55 -0700 X-IronPort-AV: E=Sophos;i="5.64,310,1559545200"; d="scan'208";a="161253719" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.226]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 02:39:54 -0700 Date: Fri, 26 Jul 2019 10:39:51 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: "dev@dpdk.org" , Thomas Monjalon Message-ID: <20190726093951.GA1629@bricha3-MOBL.ger.corp.intel.com> References: <29cf5458-8459-0187-13b1-44277283fc93@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29cf5458-8459-0187-13b1-44277283fc93@intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] Should we disallow running secondaries after primary has died? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jul 26, 2019 at 10:05:02AM +0100, Burakov, Anatoly wrote: > 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) > Documenting this limitation seems a good thing to do. I'm not sure that it's worthwhile trying to make the scenario (of running a secondary after a primary has terminated) supported. /Bruce