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 C0E66A0526; Wed, 8 Jul 2020 21:37:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B28681DAD8; Wed, 8 Jul 2020 21:37:25 +0200 (CEST) Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id AF0DD1DA8E for ; Wed, 8 Jul 2020 21:37:23 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20200708193722euoutp0127cc1557f57355d8b20cac04544555b6~f3iTCRFRm0988909889euoutp01y for ; Wed, 8 Jul 2020 19:37:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200708193722euoutp0127cc1557f57355d8b20cac04544555b6~f3iTCRFRm0988909889euoutp01y DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1594237042; bh=6Ln8LphgWmCl/SXnjS0y0PQAIGnka4s2BBgHXCFYg1s=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=Eib9l3rpDjEJhld7gxVkZV1dSuwpahQ5T1vCek3GNu1NmcHz71h/0f9emEZSaUs5x Z4w89xFM+DQ2yCkb2idLOozPA5hHwCM60kU0q2FJXh1DFI3MwJyh804CtN77wKdZbp KUXAWfRpeSADIKrkn025qCSLaUNLklmzK1G8eQp8= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200708193722eucas1p252e9b2cdebf5ee6b2c1eb1ea521413d0~f3iSiz0HU1484514845eucas1p2H; Wed, 8 Jul 2020 19:37:22 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id AA.15.06318.170260F5; Wed, 8 Jul 2020 20:37:21 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20200708193721eucas1p149082411b1921fdf5593e61a495f1c87~f3iSIOnxR1063210632eucas1p1E; Wed, 8 Jul 2020 19:37:21 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20200708193721eusmtrp2c802b6bca51fba74fcdf8572e577ae43~f3iSHlXrW0717307173eusmtrp2O; Wed, 8 Jul 2020 19:37:21 +0000 (GMT) X-AuditID: cbfec7f5-371ff700000018ae-5e-5f062071deba Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id AF.C0.06017.170260F5; Wed, 8 Jul 2020 20:37:21 +0100 (BST) Received: from [106.210.88.70] (unknown [106.210.88.70]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20200708193721eusmtip1def486547d8059b5d74582fa005f87e8~f3iRmhZJZ0488204882eusmtip1e; Wed, 8 Jul 2020 19:37:20 +0000 (GMT) To: David Marchand Cc: Jerin Jacob Kollanukkaran , "dev@dpdk.org" , "stable@dpdk.org" , "Van Haaren, Harry" From: Lukasz Wojciechowski Message-ID: <0ea9101c-3248-22cb-85a1-1b1f08e44069@partner.samsung.com> Date: Wed, 8 Jul 2020 21:37:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH++3ebXfD2c9peNLAGAUmNA0Fh5ZYSMz+StD+SHxMvajkpu6q Zf+kSGE+0JQyN3M+KqcoxtKpYROW5GOZZFgWmCKaOdDQWuY7r1fJ/z7nnO95fOFQhFTP96BS NVm0VqNKkwnEpPnt2ujZzJOCOL+hnUBFl7FIoFha6eIp8sv+kIrSUT1SbBduCkP5yvW6Z3xl Y+8CT1lZ/4FQ/rSMC66S18Xnk+i01Bxa6xsSL04xmPKFGT1Hb9nsHSgPLTsVIREFOACmSw0C lqXYiKD+bxTHvxHYOr2LkHiXfyHoLq7iHTTcn6rkcYUmBHdfriAuWERgMo+RrMoV+8G8rppg 2Q3L4YHZRLIiArciaLW07YkE+AL0Vzv4RYiiJPgyLL/LYNMkPgVbq2OI5WM4FtoXuvY2S7AL DFXP7rWKcAR8sq8LWSawFxR06gmO3eHrrGHvOsDPhfDeNIHY+YDDoGBQyDlwBftAxz6fgJ2e A70ZwfjGGuKCPgSfS437qmB4s70hYAcR+Ay0v/Ll0heh/PEwyc13holFF+4GZ6gwVxFcWgKF 96ScWg5zJQ/RwdrNtlmyHMl0h5zpDrnRHXKj+7+3DpEtyJ3OZtTJNOOvoW/KGZWaydYkyxPT 1Sa0+zK27QFHN7JsJlgRppDMSfLDxI+T8lU5TK7aioAiZG6SSyO2WKkkSZV7m9amx2mz02jG ijwpUuYu8W9YiJHiZFUWfYOmM2jtQZVHiTzyUGVwf1lQvAEHXlt9UnenJ3RyrgWiB5u/GMM+ yoZC7L21TycTSqUzqaIAn6ygaBMVbk3MfhQQMmNJavpWY+yeIvs94mvbKmpOR1mI+fXlhsjj P5oZvcuLIzHT363FnpleUY6IEZUgMrwh3NGn1A2UdDa+XkpcveJa4Gf2Ht5akZFMiuqcD6Fl VP8AQPnBXS4DAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsVy+t/xu7qFCmzxBnt75S22r+his3j3aTuT RWP/NxaL3vOzGS3+dfxhd2D1+LVgKavH4j0vmTwmL7zI7PF+31W2AJYoPZui/NKSVIWM/OIS W6VoQwsjPUNLCz0jE0s9Q2PzWCsjUyV9O5uU1JzMstQifbsEvYz5mxrZC3byV5x+tYWxgfEj TxcjJ4eEgIlE5/3JTCC2kMBSRom+G7ZdjBxAcRmJD5cEIEqEJf5c62LrYuQCKnnNKHHm3RoW kISwgIHE81kzmUFsEQE9iYnbNrGAFDELrGGUuHlzOTtEx3smiV+Tz4JtYBOwlTgy8ysryAZe ATeJj2cKQMIsAioSf79fYgSxRQXiJJZvmc8OYvMKCEqcnPkEbBmnQKDEtVe/wOLMAmYS8zY/ ZIaw5SWat86GssUlbj2ZzzSBUWgWkvZZSFpmIWmZhaRlASPLKkaR1NLi3PTcYiO94sTc4tK8 dL3k/NxNjMC42nbs55YdjF3vgg8xCnAwKvHwvtjEGi/EmlhWXJl7iFGCg1lJhNfp7Ok4Id6U xMqq1KL8+KLSnNTiQ4ymQM9NZJYSTc4HxnxeSbyhqaG5haWhubG5sZmFkjhvh8DBGCGB9MSS 1OzU1ILUIpg+Jg5OqQZG5oBfrI1zN/KLvp2hufPK0Sen3zx8Fzpvy98kbq4DQgrLg0/c6y30 O1loXBRgXF1cYt8hYbRy9hqbabPnHnmtPCHpp/gS073O/Uz3NHbN01tXd+yQasNciy+HGAxa 9k43Xf+gOKhVaVux93P7npA97QKHmIIW704//mKNpJNcdtVKpVunV5wsUmIpzkg01GIuKk4E AFdodbvBAgAA X-CMS-MailID: 20200708193721eucas1p149082411b1921fdf5593e61a495f1c87 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200708133748eucas1p2dbe34d8605d8f618559daee9cbeaa73d X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200708133748eucas1p2dbe34d8605d8f618559daee9cbeaa73d References: <20200428012139.32196-1-l.wojciechow@partner.samsung.com> <20200708133733.29468-1-l.wojciechow@partner.samsung.com> Subject: Re: [dpdk-dev] [PATCH v2] 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.07.2020 o 19:10, David Marchand pisze: > On Wed, Jul 8, 2020 at 4:52 PM Van Haaren, Harry > wrote: >>> 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. >>> This has been fixed in test app and clarified in API documentation. >>> >>> Setting the state to WAIT in rte_service_runner_func is premature >>> as the rte_service_runner_func function is still a part of the lcore >>> function delegated to slave lcore. The state is overwritten anyway in >>> slave lcore thread loop. This premature setting state to WAIT might >>> however cause rte_eal_lcore_wait, that was called by the application, >>> to return before slave lcore thread set the FINISHED state. That's >>> why it is removed from librte_eal rte_service_runner_func function. > Thanks for the explanation and fix. > >>> Bugzilla ID: 464 >>> Fixes: 21698354c832 ("service: introduce service cores concept") >>> Fixes: f038a81e1c56 ("service: add unit tests") >>> Cc: stable@dpdk.org >>> > Reported-by: Sarosh Arif >>> Signed-off-by: Lukasz Wojciechowski >> Acked-by: Harry van Haaren > Applied, thanks Lukasz. > Great, thank you -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciechow@partner.samsung.com