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 23212A0350; Tue, 30 Jun 2020 12:35:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0B4AF1BEA3; Tue, 30 Jun 2020 12:35:08 +0200 (CEST) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by dpdk.org (Postfix) with ESMTP id 8A2091BE8E for ; Tue, 30 Jun 2020 12:35:06 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 8A287974; Tue, 30 Jun 2020 06:35:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 30 Jun 2020 06:35:05 -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= bQ7rBbGt53pRegJUe4lEjZIcFTcHFStmVvUxFKZgJBE=; b=oehqFJLtnEOeWLZ/ 5zwm9Pfy4bB6i6ROGN8suX9EnCgEH1eob5nCRbzw82CfFCJ6d8Q3S9qOgHfmzA8+ USvZ8eixd/0/PqNGEqEimIKMAsLq2bZZg2VE6clhhrk5IMyZ1eNhRZ5+w1Dz8stO MnLnvOIepxg87/GJnyszGZ/pOayKa5FlgRlr4qTn2/QRD9TH2OkxDbwPt01vgdYK EJNUdD8Ce1U1ltNrIfEYm7SkWqPns8o7U3m/jhZ2hZlvJ6xZ+wyaXhqSXUXKtE9k NG3ai32R4uBH3iuu8MaBueqvWQ+E8VtWP4Mrw/saQMZAj7YZKxr8pKIiXh/zVhWy tvJDsA== 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=bQ7rBbGt53pRegJUe4lEjZIcFTcHFStmVvUxFKZgJ BE=; b=XLq2O4ic+bV5FfLs6ZNBgtrpO0w8agzr8mYYarihez6dEzZHam7XVsRT/ cPWYSsT0Uj1LZvAI+hPSLvkWrimXVqKKAI8P2HqCm9E7s7Y1RF2SR629pz8Dc9Hn Z+FDkqcHWu2n6MOesIZPBAjdq0DxZLCuVwTTkIr+1sjk+eePMj1iKhoKYHKSeHLb 28ZiZnryVFAxcJ+ybdf0ShQPtBKFUgA1JNbqkQZHV3Vl4kIr/6Iy6sEh3mlctYDE 60CZq5G+F+3EJDUFfF9EKJSbo+3wDcU+CRTzuSUEPDiMIFtjH4oi7aTxZQwE1zAU Fvre8UBywy0/1Kz9eypwTsCmENPmw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddtucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh ephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofho nhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrth htvghrnhepgeejfffhhfeghfetveffgeffteelveekhffghfefgedvleeuveetfffgudel vefhnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepjeejrddufeegrddvtd efrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 289C1328005A; Tue, 30 Jun 2020 06:35:01 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" , David Marchand Cc: dev@dpdk.org, "jerinjacobk@gmail.com" , "Richardson, Bruce" , "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: Tue, 30 Jun 2020 12:35:00 +0200 Message-ID: <2939263.AvGHZF5Fiy@thomas> In-Reply-To: References: <20200610144506.30505-1-david.marchand@redhat.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" 26/06/2020 16:43, David Marchand: > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin > wrote: > > > > Do you mean - make this new dynamic-lcore API return an error if callied > > > > from secondary process? > > > > > > Yes, and prohibiting from attaching a secondary process if dynamic > > > lcore API has been used in primary. > > > I intend to squash in patch 6: > > > https://github.com/david-marchand/dpdk/commit/e5861ee734bfe2e4dc23d9b919b0db2a32a58aee > > > > But secondary process can attach before lcore_register, so we'll have some sort of inconsistency in behaviour. > > If the developer tries to use both features, he gets an ERROR log in > the two init path. > So whatever the order at runtime, we inform the developer (who did not > read/understand the rte_thread_register() documentation) that what he > is doing is unsupported. I agree. Before this patch, pinning a thread on a random core can trigger some issues. After this patch, register an external thread will take care of logging errors in case of inconsistencies. So the user will know he is doing something not supported by the app. It is an nice improvement. > > If we really want to go ahead with such workaround - It is not a workaround. It is fixing some old issues and making clear what is really impossible. > > probably better to introduce explicit EAL flag ( --single-process or so). > > As Thomas and Bruce suggested, if I understood them properly. No I was thinking to maintain the tri-state information: - secondary is possible - secondary is attached - secondary is forbidden Asking the user to use an option to forbid attaching a secondary process is the same as telling him it is forbidden. The error log is enough in my opinion. > A EAL flag is a stable API from the start, as there is nothing > describing how we can remove one. > So a new EAL flag for an experimental API/feature seems contradictory. > > Going with a new features status API... I think it is beyond this series. > > Thomas seems to suggest an automatic resolution when features conflict > happens.. ? I suggest allowing the maximum and raise an error when usage conflicts. It seems this is what you did in v4. > I'll send the v4, let's discuss it there if you want.