From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5FD3BA034F; Fri, 26 Feb 2021 09:26:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F0396407FF; Fri, 26 Feb 2021 09:26:33 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by mails.dpdk.org (Postfix) with ESMTP id 91B4040692 for ; Fri, 26 Feb 2021 09:26:32 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id D045C580421; Fri, 26 Feb 2021 03:26:30 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 26 Feb 2021 03:26:30 -0500 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=fm3; bh= GRumdij+iaPc7csAbdC42+Bbc/Olr6KEg+ijWFWZnI8=; b=GHxGVqaI1f/Xrdnt JK3qOfD385YIp+hWv97VpZhOot0qAIb0RklQ17t4Rt+wFAVISQFhN8yloCB3cigo 72yzuH5jyp7ozVlbxyYhFHtMl9ukMb0WtkgBSw8v94zPzMvnEQ9xG2CXSScCJnIT qrNuPgWGTJbmEKdjPY4klzi9iNARtmgYeTlpME1qFDAWc81a3sxp0HMl+NJ1Oz0O d0ZFkuym4kBYllzlUX7lSuvA4uQaCuWP6w7OXHQ/HmjSyMbsM3nKOon7ePCYAvVG PMH6IiU3km0V4GmkusQd/azppbU7nK9KEAbm328uoWdOOyRPsPOUlyoSz+y/kLQn 7aOKuw== 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=fm2; bh=GRumdij+iaPc7csAbdC42+Bbc/Olr6KEg+ijWFWZn I8=; b=Ufg0Gci+i2J5eZ83xhSSEXxPFUjqEGenEgCV3LMfXD3TgQoJOXGcwUqEI UBOyNHG85oGbCJmgHjbnPJpdqPHX3u0s198I5BRCePjz+L1FPasPQ2Yf3OwrjJNk otIqj1ikRlOfKTqgS6URuLEuZY0t3M9PkLCUr1yi1eDOjTDrmksN15laPdt2BD2q DIISWs1/2Tt39yENn3Qvb1LWKFGHAluChP0H4rqkSAFJ+uWI8ouDy63tRAid05E5 r4+MidOCfZRDcfiCzsah44shA+btTb3R1AA9j2uqcuDWxBRevBhHYJB52GIvyn9A B9YSay1hlJhktNBO03zHhYDuiPfXg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrledtgdduvddvucetufdoteggodetrfdotf 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 A69CB240067; Fri, 26 Feb 2021 03:26:28 -0500 (EST) From: Thomas Monjalon To: Feifei Wang , "david.marchand@redhat.com" , "konstantin.ananyev@intel.com" , Honnappa Nagarahalli Cc: "hemant.agrawal@nxp.com" , "Nipun.gupta@nxp.com" , "jerinj@marvell.com" , "harry.van.haaren@intel.com" , "bruce.richardson@intel.com" , "dmitry.kozliuk@gmail.com" , "navasile@linux.microsoft.com" , "dmitrym@microsoft.com" , "pallavi.kadam@intel.com" , "dev@dpdk.org" , Ruifeng Wang , nd Date: Fri, 26 Feb 2021 09:26:26 +0100 Message-ID: <36690444.8nk3bCcZ7h@thomas> In-Reply-To: References: <20210224212018.17576-1-honnappa.nagarahalli@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC 3/5] eal: lcore state FINISHED is not required X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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/02/2021 00:33, Honnappa Nagarahalli: > +Thomas, David, Konstantin for input > > > > > > Subject: [RFC 3/5] eal: lcore state FINISHED is not required > > > > > > FINISHED state seems to be used to indicate that the worker's update > > > of the 'state' is not visible to other threads. There seems to be no > > > requirement to have such a state. > > > > I am not sure "FINISHED" is necessary to be removed, and I propose some of my > > profiles for discussion. > > There are three states for lcore now: > > "WAIT": indicate lcore can start working > > "RUNNING": indicate lcore is working > > "FINISHED": indicate lcore has finished its working and wait to be reset > If you look at the definitions of "WAIT" and "FINISHED" states, they look similar, except for "wait to be reset" in "FINISHED" state . The code really does not do anything to reset the lcore. It just changes the state to "WAIT". > > > > > From the description above, we can find "FINISHED" is different from "WAIT", it > > can shows that lcore has done the work and finished it. Thus, if we remove > > "FINISHED", maybe we will not know whether the lcore finishes its work or just > > doesn't start, because this two state has the same tag "WAIT". > Looking at "eal_thread_loop", the worker thread sets the state to "RUNNING" before sending the ack back to main core. After that it is guaranteed that the worker will run the assigned function. Only case where it will not run the assigned function is when the 'write' syscall fails, in which case it results in a panic. Quick note: it should not panic. We must find a way to return an error without crashing the whole application. > > Furthermore, consider such a scenario: > > Core 1 need to monitor Core 2 state, if Core 2 finishes one task, Core 1 can start > > its working. > > However, if there is only one tag "WAIT", Core 1 maybe start its work at the > > wrong time, when Core 2 still does not start its task at state "WAIT". > > This is just my guess, and at present, there is no similar application scenario in > > dpdk. > To be able to do this effectively, core 1 needs to observe the state change from WAIT->RUNNING->FINISHED. This requires that core 1 should be calling rte_eal_remote_launch and rte_eal_wait_lcore functions. It is not possible to observe this state transition from a 3rd core (for ex: a worker might go from RUNNING->FINISHED->WAIT->RUNNING which a 3rd core might not be able to observe). > > > > > On the other hand, if we decide to remove "FINISHED", please consider the > > following files: > > 1. lib/librte_eal/linux/eal_thread.c: line 31 > > lib/librte_eal/windows/eal_thread.c: line 22 > > lib/librte_eal/freebsd/eal_thread.c: line 31 > I have looked at these lines, they do not capture "why" FINISHED state is required. > > 2. > > lib/librte_eal/include/rte_launch.h: line 24, 44, 121, 123, 131 3. examples/l2fwd- > > keepalive/main.c: line 510 > > rte_eal_wait_lcore(id_core) can be removed. Because the core state has been > > checked as "WAIT", this is a redundant operation