From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CFCAC433E0 for ; Wed, 24 Jun 2020 10:08:35 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 2DEA320C09 for ; Wed, 24 Jun 2020 10:08:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=monjalon.net header.i=@monjalon.net header.b="JnO/fFMi"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ctuTD/jJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2DEA320C09 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=monjalon.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 370E91D8FF; Wed, 24 Jun 2020 12:08:34 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 935DB1D8FD for ; Wed, 24 Jun 2020 12:08:32 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id D2FBF5809F6; Wed, 24 Jun 2020 06:08:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 24 Jun 2020 06:08:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= RjKKUQcRtXqtsWw+7KSF/iF25oPdTvjW3jV0hJH6yRo=; b=JnO/fFMiNe/e6R+8 +kqeB7d2Yw8g/eFm7xuIwTIkwaA6SpPwA9w1IbXyLtSlZWCZv3ydzd4ezz/NLQy1 3MTbvU3W8GEUUS9DZEiGXaGMFDnMq73U+TGBHpyf6fsPaNHVt+NQLrdstYtyL53q 4NNSnjOlv9dqtOOQ71TFVcNI2Y9GkAw8iGzb8JvbLK6N0zB0Xm7WHnYaz88NGhzn hrD63DqvWqyKFX4R/160H9Adr6FkS45jlp4LBVw9zLT/OXYUMeBebBprMxbJVULS 9fBguW0rOC6vFMDErolG+zlIBg+/TcxIXQJmcUOqlBEaYYT8ViEtqAZzk6ypnIIT BJCGog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=RjKKUQcRtXqtsWw+7KSF/iF25oPdTvjW3jV0hJH6y Ro=; b=ctuTD/jJ2bKm5eilUKRuJlpnVZqAL02PO9e1kjrRiVT8boEk8hs2oL/j5 o+Agw+Ma0fcypKs/sBvsRSAjaG1YZaOUfr6pwhr2JqfVu1KVtc4QxNPWXrlmat/J cCaU+OaaT4UrAVUdSukHofjEUQUEsr4pYbBYTV/ob/RvFlRriqgT61UVo5It+NFm VVMgGdm9/Gr1qE0csoJKxdJ/nPCVwRGT4om1TpHDMwX//ITpau3Gt0qqllKuiYrH lPGwP+dVKmHU1HrhO0dCrUFyUZKbwoiN3f+bhI1hbljlDrkITaFHncd+3q2EkzCK WDiCPPuBJmMjvGUaWxEIABFxYVyQg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D33B3280063; Wed, 24 Jun 2020 06:08:27 -0400 (EDT) From: Thomas Monjalon To: David Marchand , Bruce Richardson Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "jerinjacobk@gmail.com" , "mdr@ashroe.eu" , "ktraynor@redhat.com" , "Stokes, Ian" , "i.maximets@ovn.org" , "Mcnamara, John" , "Kovacevic, Marko" , "Burakov, Anatoly" , Olivier Matz , Andrew Rybchenko , Neil Horman Date: Wed, 24 Jun 2020 12:08:26 +0200 Message-ID: <2150079.oGfeyVPo5L@thomas> In-Reply-To: <20200624095606.GA929@bricha3-MOBL.ger.corp.intel.com> References: <20200610144506.30505-1-david.marchand@redhat.com> <20200624095606.GA929@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 24/06/2020 11:56, Bruce Richardson: > 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. Same thought here. I like the idea of a "mode flag" when multi-process is in use. Should it be an user explicit flag or an automatic one?