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 7CF09A046B for ; Fri, 26 Jul 2019 18:02:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ED48A1C492; Fri, 26 Jul 2019 18:02:19 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id A1AB21C47B for ; Fri, 26 Jul 2019 18:02:17 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 09:02:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,311,1559545200"; d="scan'208";a="369570897" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.25.220]) ([10.252.25.220]) by fmsmga005.fm.intel.com with ESMTP; 26 Jul 2019 09:02:14 -0700 To: "Lipiec, Herakliusz" , Stephen Hemminger Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , "dev@dpdk.org" , Thomas Monjalon References: <29cf5458-8459-0187-13b1-44277283fc93@intel.com> <20190726093951.GA1629@bricha3-MOBL.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580168A5BA83@irsmsx105.ger.corp.intel.com> <06bb50da-e56f-3bf0-920f-001480150f5d@intel.com> <20190726080116.68d766a3@hermes.lan> <8d8246b4-3791-7922-f656-b69d7b4febee@intel.com> From: "Burakov, Anatoly" Message-ID: <3df4ac13-5afc-8505-51bf-0df4b6b5efdb@intel.com> Date: Fri, 26 Jul 2019 17:02:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 26-Jul-19 4:56 PM, Lipiec, Herakliusz wrote: > > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Burakov, Anatoly >> On 26-Jul-19 4:01 PM, Stephen Hemminger wrote: >>> On Fri, 26 Jul 2019 10:53:58 +0100 >>> "Burakov, Anatoly" wrote: >>> >>>>> >>>>> NP to disallow it. >>>>> In fact, I think it would be easier for everyone just to drop >>>>> current DPDK MP model, and keep just standalone DPDK instances. >>>> >>>> That's the dream, but i don't think it'll ever come to fruition, at >>>> least not without a huge push from the community. >>> >>> There are several net appliances that require primary/secondary model. >>> I think initially during DPDK development it was sold as a feature to >>> the Network vendors. >>> >>> It might be possible to clamp down on what API's are supported by >>> secondary process. For example, disallowing any control operations start/stop >> etc. >>> >> >> We're getting slightly off topic here. >> >> The original question was about whether we want to support a use case where a >> secondary can initialize after primary process has died, and if we don't, whether >> we want to 1) outright deny initialization, or 2) allow it, but document as >> unsupported and discourage it. > Allowing something that is unsupported sounds like asking for trouble. We wouldn't be "allowing" it as much as we'd just be disclaiming any responsibility for when things go wrong, *if* someone tries that. I suppose the concern is that someone would try that /accidentally/, and possibly screw up other secondary processes that may still be running. > >> >> The only use case i can think of that would require it is proc-info app. >> Dumping stuff from a dead process can be useful for debugging, so perhaps we >> can agree to put a warning at EAL startup, saying that this is not supported, but >> still allow processes to initialize. >> > If this is supposed to be useful for debugging then maybe allow only when some kind of flag is passed to eal? > This would also prevent from initializing the process incidentally. We have too many EAL flags as it is! I suppose this could be done - proc-info already hardcodes the "--proc-type" flag so that it only ever runs as a secondary, we could add another one there. So, technically, this is doable. I'm just not sure of the prospect of adding a yet another EAL flag to serve a purpose of enabling one specific application to run. That said, an "--i-know-what-i-am-doing" flag certainly sounds like a fun idea! -- Thanks, Anatoly