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 1CF08A0350; Wed, 24 Jun 2020 11:56:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 87AAA1D8D4; Wed, 24 Jun 2020 11:56:16 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id CC4B01D8D3 for ; Wed, 24 Jun 2020 11:56:14 +0200 (CEST) IronPort-SDR: CKocASpSRK4f3iZBTcEmg4GpoRKjTMzhfxnohETEfxa+hTtY/ddEcJGUmXeUIa/PHNAMFNqgvS HmBByn/qFfoQ== X-IronPort-AV: E=McAfee;i="6000,8403,9661"; a="143488583" X-IronPort-AV: E=Sophos;i="5.75,274,1589266800"; d="scan'208";a="143488583" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2020 02:56:13 -0700 IronPort-SDR: 56DpQy5veQf4yHp4h+T9Wv1WaztT+HIH+0rv7Oyc5FbQVF/EMQvMNkEJWarVAtJBWAnZ0JzOD7 irMLNzfXB9cQ== X-IronPort-AV: E=Sophos;i="5.75,274,1589266800"; d="scan'208";a="423315078" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.31.225]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 24 Jun 2020 02:56:09 -0700 Date: Wed, 24 Jun 2020 10:56:06 +0100 From: Bruce Richardson To: David Marchand Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "jerinjacobk@gmail.com" , "mdr@ashroe.eu" , "ktraynor@redhat.com" , "Stokes, Ian" , "i.maximets@ovn.org" , Thomas Monjalon , "Mcnamara, John" , "Kovacevic, Marko" , "Burakov, Anatoly" , Olivier Matz , Andrew Rybchenko , Neil Horman Message-ID: <20200624095606.GA929@bricha3-MOBL.ger.corp.intel.com> References: <20200610144506.30505-1-david.marchand@redhat.com> <20200622132531.21857-1-david.marchand@redhat.com> <20200622132531.21857-7-david.marchand@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores 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 Wed, Jun 24, 2020 at 11:23:55AM +0200, David Marchand wrote: > On Tue, Jun 23, 2020 at 3:16 PM Ananyev, Konstantin > wrote: > > > Even before this series, MP has no protection on lcore placing between > > > primary and secondary processes. > > > > Agree, it is not a new problem, it has been there for a while. > > Though making lcore assignment dynamic will make it more noticeable and harder to avoid. > > With static only lcore distribution it is much easier to control things. > > > > > Personally, I have no use for DPDK MP and marking MP as not supporting > > > this new feature is tempting for a first phase. > > > If this is a strong requirement, I can look at it in a second phase. > > > What do you think? > > > > In theory it is possible to mark this new API as not supported for MP. > > At least for now. Though I think it is sort of temporal solution. > > AFAIK, MP is used by customers, so sooner or later someone will hit that problem. > > I understand this argument. > But then we don't see those customers giving feedback. > > > > Let say, we do have pdump app/library in our mainline. > > As I can see - it will be affected when users will start using this new dynamic lcore API > > inside their apps. > > Supporting lcore allocation in MP requires exchanges between > primary/secondary processes like what we have for memory allocations. > It will be quite a beast to get to work fine, while not even knowing > if people actually want to use both. > > For v4, I added a check to exclude MP and the new API. > I am still willing to help if people do care about using both features together. I wonder how much we could simplify DPDK generally if we had to enable a specific runtime flag to enable multi-process support and it was off by default. This would break proc_info I think, but maybe we could provide telemetry callbacks to provide the same data, but beyond that it would just allow us to know whether a DPDK app is actually using MP, or just running as a single process. /Bruce