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 5DE61A0352; Fri, 8 May 2020 19:04:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D83DC1D6F4; Fri, 8 May 2020 19:04:37 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 79C031D6EA for ; Fri, 8 May 2020 19:04:36 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200508170435euoutp02be3beff4f3de4334d1152dc2335587a4~NHGfZfpTs0430404304euoutp02F for ; Fri, 8 May 2020 17:04:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200508170435euoutp02be3beff4f3de4334d1152dc2335587a4~NHGfZfpTs0430404304euoutp02F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1588957475; bh=AxtOLBeTOGOxHNiQAwoUBKdAmRNmRxi8gfrpHawCSeY=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=rEIX3Sj2CCPEbf4ira5Ddc8xy3Clr8+1wiWxhuf6oROh0Sh/8jdvCgM7bRSN6moLA D0EkN53CBu69DDUGM5R4cag4ALuTvDZuhlbGT1XUPxcBXI+tAd5yXdceT2vpc8Guma XuZRMEg2GlIN8slKOTf6wLr6DULU/WRsVPprxCuo= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200508170435eucas1p2e8f18e8589089d47eebb38ac388e767a~NHGe5wysJ1663416634eucas1p2y; Fri, 8 May 2020 17:04:35 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id F9.27.60698.32195BE5; Fri, 8 May 2020 18:04:35 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200508170434eucas1p265994e4283ec11b5f7dbc45e9395a484~NHGejfyLd2805328053eucas1p2g; Fri, 8 May 2020 17:04:34 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200508170434eusmtrp19f6f26b8122115877f173d97ddff7538~NHGei5zO-1441214412eusmtrp1c; Fri, 8 May 2020 17:04:34 +0000 (GMT) X-AuditID: cbfec7f5-a0fff7000001ed1a-9f-5eb591237654 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 0B.74.07950.22195BE5; Fri, 8 May 2020 18:04:34 +0100 (BST) Received: from [106.210.88.70] (unknown [106.210.88.70]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20200508170430eusmtip10d024848c3931e41ea1456b9b286bf5b~NHGaa5r5U0488404884eusmtip1h; Fri, 8 May 2020 17:04:30 +0000 (GMT) To: "Van Haaren, Harry" , Phil Yang , Jerin Jacob Cc: "dev@dpdk.org" , "stable@dpdk.org" , nd From: Lukasz Wojciechowski Message-ID: <063dec25-ac33-bd53-75d0-4c20aea96959@partner.samsung.com> Date: Fri, 8 May 2020 19:04:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsWy7djPc7rKE7fGGVy9yWfx7tN2JovG/m8s FhMnmVicWd7DbLHmfTezxb+OP+wObB5r5q1h9Nhwop/V49eCpawei/e8ZApgieKySUnNySxL LdK3S+DK2D59MVvBCcWKT5/uMTcwXpfuYuTkkBAwkdj5tIW1i5GLQ0hgBaPE7r5z7BDOF0aJ lvNzmSGcz4wSJ9d3s8G03Jz7gxEisZxR4uLjeVD9bxklNh5dy9TFyMEhLGAhseSdF0hcRKCZ UeL69Slg3cwCkRInz7xiB7HZBGwljsz8ygpSzyvgJtH3KAQkzCKgInHs0gewclGBWInTizcz gti8AoISJ2c+YQGxOYHisy68Y4UYKS/RvHU2M4QtLnHryXwmkL0SAqvYJc4/uMEIcbWLxKFT W6BsYYlXx7ewQ9gyEqcn97BANGxjlLj6+ycjhLMf6OreFVBV1hKH//1mA7mUWUBTYv0ufYiw o0TzwtvsIGEJAT6JG28FIY7gk5i0bTozRJhXoqNNCKJaT+Jpz1RGmLV/1j5hmcCoNAvJa7OQ vDMLyTuzEPYuYGRZxSieWlqcm55abJyXWq5XnJhbXJqXrpecn7uJEZhwTv87/nUH474/SYcY BTgYlXh4ZxRujRNiTSwrrsw9xCjBwawkwjuxYkucEG9KYmVValF+fFFpTmrxIUZpDhYlcV7j RS9jhQTSE0tSs1NTC1KLYLJMHJxSDYxH2TyOdwvU/OW1bUuVnzdlJcu0VW8n3ZY7rujC6/eu 6pFBt/nf8y2+W5ISdmWxtmzg6/lberyufdYDnp2854OqOJtm/T7N+vKO5r0HCj/U5Rd+4czn 3qZuXD7zVM68VZ7FTzJzNYylwuU7Tv0XNtdcGnlwj3pnVu1hMQnvE4orPOIqBPrsvZVYijMS DbWYi4oTAcwHB700AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsVy+t/xu7pKE7fGGWw/Ymnx7tN2JovG/m8s FhMnmVicWd7DbLHmfTezxb+OP+wObB5r5q1h9Nhwop/V49eCpawei/e8ZApgidKzKcovLUlV yMgvLrFVija0MNIztLTQMzKx1DM0No+1MjJV0rezSUnNySxLLdK3S9DL2D59MVvBCcWKT5/u MTcwXpfuYuTkkBAwkbg59wdjFyMXh5DAUkaJlu0bWboYOYASMhIfLglA1AhL/LnWxQZR85pR 4tvmr2wgNcICFhJL3nmBxEUEmhklTjzZwQTSwCwQKTFlwWxmiIbzzBLz578GS7AJ2EocmfmV FaSZV8BNou9RCEiYRUBF4tilD2wgtqhArMTqa62MIDavgKDEyZlPWEBsTqD4rAvvWCHmm0nM 2/yQGcKWl2jeOhvKFpe49WQ+0wRGoVlI2mchaZmFpGUWkpYFjCyrGEVSS4tz03OLjfSKE3OL S/PS9ZLzczcxAuNr27GfW3Ywdr0LPsQowMGoxMM7o3BrnBBrYllxZe4hRgkOZiUR3okVW+KE eFMSK6tSi/Lji0pzUosPMZoCPTeRWUo0OR8Y+3kl8YamhuYWlobmxubGZhZK4rwdAgdjhATS E0tSs1NTC1KLYPqYODilGhh9i3N5Ozu/+ViuNa5/v7VLdIPPzz+VF+9q7u07EXa3rJ7zHXvC 5uI3DPd4kzXSD1n6nFtqoh57N8Nhpiur3468mTwsX83S5r9Icf3spXN7T0DDG8EveZVZX5NX +zmZOc/5epdX+9aGD/a/1uV9fui/Wfysc+ElVra1L5KX8MvwK1dtuKFkzKbEUpyRaKjFXFSc CADj/JbXxQIAAA== X-CMS-MailID: 20200508170434eucas1p265994e4283ec11b5f7dbc45e9395a484 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200428012204eucas1p120a84e501d0d64145c21476cd2562f36 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200428012204eucas1p120a84e501d0d64145c21476cd2562f36 References: <20200428012139.32196-1-l.wojciechow@partner.samsung.com> Subject: Re: [dpdk-dev] [PATCH] eal: fix lcore state bug 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" W dniu 08.05.2020 o 18:12, Van Haaren, Harry pisze: >> -----Original Message----- >> From: Phil Yang >> Sent: Thursday, April 30, 2020 3:54 AM >> To: Lukasz Wojciechowski ; Van Haaren, >> Harry ; Jerin Jacob >> >> Cc: dev@dpdk.org; stable@dpdk.org; nd ; nd >> Subject: RE: [dpdk-dev] [PATCH] eal: fix lcore state bug >> >>> -----Original Message----- >>> From: Lukasz Wojciechowski >>> Sent: Thursday, April 30, 2020 5:32 AM >>> To: Phil Yang ; Harry van Haaren >>> ; Jerin Jacob >>> >>> Cc: dev@dpdk.org; stable@dpdk.org; nd >>> Subject: Re: [dpdk-dev] [PATCH] eal: fix lcore state bug >>> >>> Hi Phil, >>> >>> W dniu 29.04.2020 o 17:07, Phil Yang pisze: >>>> Hi Lukasz, >>>> >>>>> -----Original Message----- >>>>> From: dev On Behalf Of Lukasz Wojciechowski >>>>> Sent: Tuesday, April 28, 2020 9:22 AM >>>>> To: Harry van Haaren ; Jerin Jacob >>>>> >>>>> Cc: dev@dpdk.org; l.wojciechow@partner.samsung.com; >>> stable@dpdk.org >>>>> Subject: [dpdk-dev] [PATCH] eal: fix lcore state bug >>>>> >>>>> The rte_service_lcore_reset_all function stops execution of services >>>>> on all lcores and switches them back from ROLE_SERVICE to ROLE_RTE. >>>>> However the thread loop for slave lcores (eal_thread_loop) distincts >>> these >>>>> roles to set lcore state after processing delegated function. >>>>> It sets WAIT state for ROLE_SERVICE, but FINISHED for ROLE_RTE. >>>>> So changing the role to RTE before stopping work in slave lcores >>>>> causes lcores to end in FINISHED state. That is why the rte_eal_lcore_wait >>>>> must be run after rte_service_lcore_reset_all to bring back lcores to >>>>> launchable (WAIT) state. >>>> Is that make sense to call rte_eal_mp_wait_lcore() inside >>> rte_serice_lcore_reset_all() ? >>> >>> yeah, I thought about it and in my opinion the answer is no, because if >>> the function run on slave lcore is in FINISHED state it means, that >>> someone can still read the value returned by the function and the only >>> one who can be interested in the value is the one that delegated the >>> service. >>> >>> If we will wait for lcores to end their jobs, read the values and switch >>> them to WAIT state, the values will be lost. The application might need >>> to read them. We cannot take this possibility from it. > I understand that on exiting, the lcore state is different per service or rte lcore. > The goal was to leave the lcore thread in a state as if it was never used. > > As Phil suggested, doing the wait() inside service cores achieves that. > Lukasz's point is that this hides the service core return code. > > Is it really a problem if application is not getting access to the return code of the service lcore? > What do we expect the application will care about? Today I'm not aware of any service-lcore > return value that the application should be checking. It would probably be convenient to don't need to remember about calling wait() after the rte_service_lcore_reset_al(). However such a change will change the current behavior of the rte_service_lcore_reset_all function. We cannot know if someone is not using it with this functionality, maybe outside of the dpdk tree. So I believe that this patch should focus on fixing the current bug, reported on bugzilla and do nothing more. IMO change of the API should be discussed and introduced separately in another patch if decided so. >> Yeah. I think that is a good point. >> >> Reviewed-by: Phil Yang >> >>>> >>>> >>>> Thanks, >>>> Phil >>> -- >>> >>> Lukasz Wojciechowski >>> Principal Software Engineer >>> >>> Samsung R&D Institute Poland >>> Samsung Electronics >>> Office +48 22 377 88 25 >>> l.wojciechow@partner.samsung.com -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciechow@partner.samsung.com