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 ED55EA0519; Fri, 3 Jul 2020 17:15:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6729F1DBED; Fri, 3 Jul 2020 17:15:38 +0200 (CEST) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by dpdk.org (Postfix) with ESMTP id 5E7D01DBE5 for ; Fri, 3 Jul 2020 17:15:36 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 12F77885; Fri, 3 Jul 2020 11:15:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 03 Jul 2020 11:15:34 -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= 30zluhqBuLdZSQb3qMia5EdyoWx4G3cCg52hjhwzIlg=; b=tf9NLyu//DYQkp+Z htYVR9EeRRLTGyKk7vRReq3l73Jcr/XKYtb0SuvtjF9zvcBeLHBw+dL0x7DH7zGG Q7KRxlgmQoRPMTwmyvk2RhIPUMsFLZ5M78fV9Tb3fxg//NyxVOEz55xQEX4TfDSt /DQqe3cKR8Z7FYdaoO5wN3OhdF1qfvaTPDCEoaScZeta6GeQEyBsuFXjiEp1S5ST a6a8bQgrkSkzTua1nZDCRIKARteDsYze6zfMkSviYNxfKUY6PehSCDlv2ZpP+hZx vcEuNuE4HPLxa9NnJN1klpPKOINcc394jjJ+ij56cuCk0PnoPKiHFqOjKkjYYZ6f /tulaA== 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=30zluhqBuLdZSQb3qMia5EdyoWx4G3cCg52hjhwzI lg=; b=HadGV86djNYrc34GGe+kxLDLNnnQHQxmC2p1eO4nZD/UnhDhyUTKL6pDw XZDfRuxrSV0Ra1382NeyRPRj56yySBYzHjQ7WXTmrIg6ZcVqqmP4uoJgZ5M13yg7 ByTphnrfH6exT46wvdUktgqBkcSKXGnUA2k42hubDFQSDpHlDioYpYouiwKC7zLR /ogf4YbSgveJymOloNgSOFZBa7rKtwY9UTUbjizoT5v5jD57NR8BZAwBBd1To2QK E47XfHXWOq7kIKPsB9yOVXint+dB61NBGiLvz1yeUXPMgyjLxIQnCUAe7/WpqIaa AvsiZE5h/IBnZYC6jHoI4ICiVpVag== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdeigdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 D01DD3060066; Fri, 3 Jul 2020 11:15:29 -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: Fri, 03 Jul 2020 17:15:28 +0200 Message-ID: <2074463.nq7fr979yV@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" 02/07/2020 15:06, David Marchand: > On Wed, Jul 1, 2020 at 1:58 PM Ananyev, Konstantin > wrote: > > > If the final users finally hit the situation you describe, it means > > > that the multiprocess had been in use so far and was known to be in > > > use (*hopefully*). > > > > Yes. > > > > > So is it not a problem of design/non-regression testing when > > > integrating the new API in the first place? > > > > Not sure I understand you here... > > If you saying that for SP benchmarking/testing current approach > > is sufficient, then - yes it is. > > Or are you saying it would be hard to create a test-case to > > reproduce such problematic scenario? > > I am saying that getting to a problematic scenario that only the final > users get, would be a failure in the development, documentation and > validation of the application. > > When the developer integrates this new API, the developer will read > the API description. > > - If the limitation on mp is understood and accepted, the application > documentation will be updated to reflect this. > Users can then know mp is not available. > If the users still try to use it, it can be a support issue. > The users will then report to support people who should be aware this > is not supported (the documentation says so). > > - If the application needs mp support because of X, Y reasons, the > developer integrating the new API, should complain upstream that the > new API requires mp support. > If the developer does not complain but still uses the API.. well too > bad (or it falls through to the following point). > > - The application needs mp support, the developer did not catch the > warning in the API (the kids are home, hard to concentrate)... > The new API will be used for datapath processing threads, so non > regression perf tests will be run. > On the other hand, the application uses mp for X, Y reasons, so there > will be associated test cases. > I can't tell for sure, but I find it hard to believe a validation team > would never do tests that combine both. Please let's conclude. The proposed API for thread registration does not support multi-process. This limitation is documented and there are some runtime checks. If this API is used in an application design, it should be clear that attaching a secondary process is forbidden. If a user tries to attach a secondary process before the application registers a thread, then future thread registration will fail. If a user tries to attach a secondary process after a thread registration, then the secondary process will fail. It means that depending on when the user *wrongly* attach a secondary process (despite the documented limitation of the application), the failure will happen in a different context. I think it is OK. The alternative is to introduce a new EAL flag or a new API to make sure the failure will happen when attaching a secondary process, even if no thread is registered yet. I think adding such addition would be weird from user or API perspective. Please note that accepting the thread registration API does not prevent from adding an EAL flag or a new API later. That's why I vote for merging this series. Acked-by: Thomas Monjalon