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 66D72A046B for ; Fri, 26 Jul 2019 18:57:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 327AB1C51A; Fri, 26 Jul 2019 18:57:49 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 2DA821C515 for ; Fri, 26 Jul 2019 18:57:47 +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 fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 09:57:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,311,1559545200"; d="scan'208";a="369584766" 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:57:44 -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> <3df4ac13-5afc-8505-51bf-0df4b6b5efdb@intel.com> From: "Burakov, Anatoly" Message-ID: <2b37da59-68fa-57e7-1bc4-63bc52e5ccb7@intel.com> Date: Fri, 26 Jul 2019 17:57:44 +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: 8bit 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 5:44 PM, Lipiec, Herakliusz wrote: > > >> -----Original Message----- >> From: Burakov, Anatoly >> >> 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. > Well it’s a bad idea to allow this without any "yes I know what I'm doing" > >> >> 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! > Well are there any other "unsupported" operations in dpdk ? > Maybe one "--i-(don’t)-know-what-i-am-doing" aka debug (devmode, dangerous or whatever) flag > is a good option to enable/disable these kind of behaviours and cover them all, > this would definitely help preventing someone from doing this accidentally, or unknowingly (for example from within a script). To be completely clear, it's not like it's /dangerous/ to allow this sort of init. At least not currently. Things like ports will be missing from the process, but usually initialization is *attaching* to data, not creating new one. So, allowing such unsupported scenario is, strictly speaking, safe, at least for now. I am not aware of any other "unsupported" operations that DPDK allows you to do, so that would be a first. There are debug modes for various libraries, but 1) they're compile time, 2) they're compile time for performance reasons, meaning we can't bake them in and enable them with a switch, and 3) they're not "unsupported", they're just not the default. > >> >> -- >> Thanks, >> Anatoly -- Thanks, Anatoly