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 E70ACA0350; Tue, 23 Jun 2020 11:14:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5B8EE1D5B1; Tue, 23 Jun 2020 11:14:35 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id D3A5C1D5AE for ; Tue, 23 Jun 2020 11:14:32 +0200 (CEST) IronPort-SDR: ZaWGBH+6pgR6Ykit1C/trvmFkFfazyPglNCyMBpAnkUWlNnxeoN3CwvJV2P1Da8uB4C801vgs8 hhQipCTiKNMw== X-IronPort-AV: E=McAfee;i="6000,8403,9660"; a="141515301" X-IronPort-AV: E=Sophos;i="5.75,270,1589266800"; d="scan'208";a="141515301" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2020 02:14:31 -0700 IronPort-SDR: XaTp+xfSXSfJV5q18ZJWJqRDFNTcHP9aND+lgxY6naYfhFgMtTDSx6DMaPYnrGhC/nmMPwsOmH Gep2G4teJSHA== X-IronPort-AV: E=Sophos;i="5.75,270,1589266800"; d="scan'208";a="452160901" Received: from unknown (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.30.229]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 23 Jun 2020 02:14:27 -0700 Date: Tue, 23 Jun 2020 10:14:24 +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: <20200623091424.GA599@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 Tue, Jun 23, 2020 at 09:49:18AM +0200, David Marchand wrote: > Hello Konstantin, > > On Mon, Jun 22, 2020 at 5:49 PM Ananyev, Konstantin > wrote: > > > diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c > > > index 86d32a3dd7..7db05428e7 100644 > > > --- a/lib/librte_eal/common/eal_common_lcore.c > > > +++ b/lib/librte_eal/common/eal_common_lcore.c > > > @@ -220,3 +221,38 @@ rte_socket_id_by_idx(unsigned int idx) > > > } > > > return config->numa_nodes[idx]; > > > } > > > + > > > +static rte_spinlock_t lcore_lock = RTE_SPINLOCK_INITIALIZER; > > > + > > > +unsigned int > > > +eal_lcore_non_eal_allocate(void) > > > +{ > > > + struct rte_config *cfg = rte_eal_get_configuration(); > > > + unsigned int lcore_id; > > > + > > > + rte_spinlock_lock(&lcore_lock); > > > > I think it will break current DPDK MP modes. > > The problem here - rte_config (and lcore_role[]) is in shared memory, > > while the lock is local. > > Simplest way probably to move lcore_lock to rte_config. > > Even before this series, MP has no protection on lcore placing between > primary and secondary processes. > 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? > I think that is reasonable for a new feature. I suspect those wanting to dynamically manage their own threads probably do not care about multi-process mode. However, this limitation probably needs to be clearly called out in the docs. /Bruce