Patch Comment List
List patch comments
GET /api/patches/74493/comments/?format=api
[ { "id": 116306, "web_url": "https://patches.dpdk.org/comment/116306/", "msgid": "<fbd9c539-24c1-8cd8-988f-56dd423f892d@partner.samsung.com>", "list_archive_url": "https://inbox.dpdk.org/dev/fbd9c539-24c1-8cd8-988f-56dd423f892d@partner.samsung.com", "date": "2020-07-20T12:51:56", "subject": "Re: [dpdk-dev] [PATCH] service: fix stop API to wait for service\n\tthread", "submitter": { "id": 1628, "url": "https://patches.dpdk.org/api/people/1628/?format=api", "name": "Lukasz Wojciechowski", "email": "l.wojciechow@partner.samsung.com" }, "content": "W dniu 20.07.2020 o 14:09, Harry van Haaren pisze:\n> This commit improves the service_lcore_stop() implementation,\n> waiting for the service core in question to return. The service\n> thread itself now has a variable to indicate if its thread is\n> active. When zero the service thread has completed its service,\n> and has returned from the service_runner_func() function.\n>\n> This fixes a race condition observed in the DPDK CI, where the\n> statistics of the service were not consistent with the expectation\n> due to the service thread still running, and incrementing a stat\n> after stop was called.\n>\n> Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>\n>\n> ---\n>\n> This is one possible solution, that avoids a class of race-conditions\n> based on stop() api and following behaviours. Without a change in\n> implementation of the service core thread, we could not detect when\n> the thread was actually finished. This is now possible, and the stop\n> api makes use of it to wait for 1000x one millisecond, or log a warning\n> that a service core didn't return quickly.\n>\n> Thanks for the discussion/debug on list - I'm not sure how to add\n> reported-by/suggested-by etc tags: but I'll resend a V2 (or can add\n> on apply).\n>\n> ---\n> lib/librte_eal/common/rte_service.c | 24 ++++++++++++++++++++++++\n> 1 file changed, 24 insertions(+)\n>\n> diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c\n> index 6a0e0ff65..d2255587d 100644\n> --- a/lib/librte_eal/common/rte_service.c\n> +++ b/lib/librte_eal/common/rte_service.c\n> @@ -65,6 +65,7 @@ struct core_state {\n> \t/* map of services IDs are run on this core */\n> \tuint64_t service_mask;\n> \tuint8_t runstate; /* running or stopped */\n> +\tuint8_t thread_active; /* indicates when the thread is in service_run() */\n> \tuint8_t is_service_core; /* set if core is currently a service core */\n> \tuint8_t service_active_on_lcore[RTE_SERVICE_NUM_MAX];\n> \tuint64_t loops;\n> @@ -457,6 +458,8 @@ service_runner_func(void *arg)\n> \tconst int lcore = rte_lcore_id();\n> \tstruct core_state *cs = &lcore_states[lcore];\n> \n> +\t__atomic_store_n(&cs->thread_active, 1, __ATOMIC_RELAXED);\n> +\n> \t/* runstate act as the guard variable. Use load-acquire\n> \t * memory order here to synchronize with store-release\n> \t * in runstate update functions.\n> @@ -475,6 +478,7 @@ service_runner_func(void *arg)\n> \t\tcs->loops++;\n> \t}\n> \n> +\t__atomic_store_n(&cs->thread_active, 0, __ATOMIC_RELAXED);\n> \treturn 0;\n> }\n> \n> @@ -765,6 +769,26 @@ rte_service_lcore_stop(uint32_t lcore)\n> \t__atomic_store_n(&lcore_states[lcore].runstate, RUNSTATE_STOPPED,\n> \t\t__ATOMIC_RELEASE);\n> \n> +\t/* wait for service lcore to return */\n> +\ti = 0;\n> +\tuint8_t active;\n> +\tuint64_t start = rte_rdtsc();\n> +\tdo {\n> +\t\tactive = __atomic_load_n(&lcore_states[lcore].thread_active,\n> +\t\t\t\t\t __ATOMIC_RELAXED);\n> +\t\tif (active == 0)\n> +\t\t\tbreak;\n> +\t\trte_delay_ms(1);\n> +\t\ti++;\n> +\t} while (i < 1000);\n> +\n> +\tif (active != 0) {\n> +\t\tuint64_t end = rte_rdtsc();\n> +\t\tRTE_LOG(WARNING, EAL,\n> +\t\t\t\"service lcore stop() failed, waited for %ld cycles\\n\",\n> +\t\t\tend - start);\n> +\t}\n> +\n> \treturn 0;\n> }\n> \nI don't like the idea of inserting this polling loop inside API call. \nAnd I don't like setting up a 1000 iterations constraint.\nHow about keeping the thread_active flag, but moving checking state of \nthis flag to separate function. This way the user of the API would be \nable to write own loop.\nMaybe he/she would like a custom loop, because:\n* waiting for more cores\n* would like to wait longer\n* would like to check if service is finished less often...", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 60496A0540;\n\tMon, 20 Jul 2020 14:52:02 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id D026529CB;\n\tMon, 20 Jul 2020 14:52:01 +0200 (CEST)", "from mailout1.w1.samsung.com (mailout1.w1.samsung.com\n [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id EA12B1023\n for <dev@dpdk.org>; Mon, 20 Jul 2020 14:52:00 +0200 (CEST)", "from eucas1p1.samsung.com (unknown [182.198.249.206])\n by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id\n 20200720125200euoutp012ab46d540e22bb46d5fae285475282cb~jdvyjB3aD2075320753euoutp01E\n for <dev@dpdk.org>; Mon, 20 Jul 2020 12:52:00 +0000 (GMT)", "from eusmges1new.samsung.com (unknown [203.254.199.242]) by\n eucas1p1.samsung.com (KnoxPortal) with ESMTP id\n 20200720125200eucas1p1d7f4b59a9380f226814251baf7ffcc03~jdvyWB4633096630966eucas1p1S;\n Mon, 20 Jul 2020 12:52:00 +0000 (GMT)", "from eucas1p2.samsung.com ( [182.198.249.207]) by\n eusmges1new.samsung.com (EUCPMTA) with SMTP id E1.AE.06456.073951F5; Mon, 20\n Jul 2020 13:52:00 +0100 (BST)", "from eusmtrp1.samsung.com (unknown [182.198.249.138]) by\n eucas1p2.samsung.com (KnoxPortal) with ESMTPA id\n 20200720125159eucas1p217be2baca613a022ae05d6ba59c6e1eb~jdvx0rmJ81998619986eucas1p2V;\n Mon, 20 Jul 2020 12:51:59 +0000 (GMT)", "from eusmgms2.samsung.com (unknown [182.198.249.180]) by\n eusmtrp1.samsung.com (KnoxPortal) with ESMTP id\n 20200720125159eusmtrp1e2fe1cf6d523448d7178def59c44e054~jdvxz6F1l1012410124eusmtrp1a;\n Mon, 20 Jul 2020 12:51:59 +0000 (GMT)", "from eusmtip1.samsung.com ( [203.254.199.221]) by\n eusmgms2.samsung.com (EUCPMTA) with SMTP id 09.13.06017.F63951F5; Mon, 20\n Jul 2020 13:51:59 +0100 (BST)", "from [106.210.88.70] (unknown [106.210.88.70]) by\n eusmtip1.samsung.com (KnoxPortal) with ESMTPA id\n 20200720125158eusmtip1f731f147c7798be296ef6b04a2cc59ae~jdvw6RZSG0037600376eusmtip1e;\n Mon, 20 Jul 2020 12:51:58 +0000 (GMT)" ], "DKIM-Filter": "OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com\n 20200720125200euoutp012ab46d540e22bb46d5fae285475282cb~jdvyjB3aD2075320753euoutp01E", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;\n s=mail20170921; t=1595249520;\n bh=dih+5fa+O0dvGCMx3EbmUpAmJAOHKZNi1naA5+bIUrM=;\n h=Subject:To:Cc:From:Date:In-Reply-To:References:From;\n b=pqTegOfq72wA0X33vXTdQWhV9BL9lCNLdOVbVwpGESAChRwp/vzQh16UBO+hyeIru\n +6K5feZX2KtOaozp0w7vz6X0kM8x/7y5+GH0zClKPOb2NQtwQJyyCU0RoXzvGkBOJP\n j2Kfc5sgQsSOCEs90e0Kdxb87SOZgrF5lc/JHUQo=", "X-AuditID": "cbfec7f2-7efff70000001938-b5-5f159370951c", "To": "Harry van Haaren <harry.van.haaren@intel.com>, dev@dpdk.org", "Cc": "david.marchand@redhat.com, igor.romanov@oktetlabs.ru,\n honnappa.nagarahalli@arm.com, ferruh.yigit@intel.com, nd@arm.com,\n aconole@redhat.com", "From": "Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>", "Message-ID": "<fbd9c539-24c1-8cd8-988f-56dd423f892d@partner.samsung.com>", "Date": "Mon, 20 Jul 2020 14:51:56 +0200", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101\n Thunderbird/68.10.0", "MIME-Version": "1.0", "In-Reply-To": "<20200720120938.34660-1-harry.van.haaren@intel.com>", "Content-Transfer-Encoding": "8bit", "Content-Language": "en-US", "X-Brightmail-Tracker": [ "\n H4sIAAAAAAAAA01SfyyUcRzue+97d6+bs6/DfKbGXPlDFln+eDcRLbota/6prV+uw7tjzrE7\n RLPF6AdpCWXOhukHMxxNzuTIXZLdtVYRE2WNK78ionFS7l6W/57P83k+3+d5ti9FiFq4HlSi\n Mo1RKWUKMU9Atr9ae3sotdRNerjV6Eivz03waV19IY/+saTj0GN6E5/OvbtK0hVT+XzaUJpE\n m+uKiDBK0ljViCTrNY+5kodd0xzJ8MoMV7LQPcSL5p4XHI1nFIkZjCog9LIgocXYRqZ2e2be\n 3HjBy0FlUIgcKMBBYF7PJ21YhOsRNPXGFiLBFv6F4Of1Dzx2WEagX7Tydy6sA018dlGHINc4\n RLDDPILO1V7CpnLBEfD6j5ljw674GCwPmjg2EYFLEFimGu1P8XAIvKxY4dqwEEdCnb5wS0RR\n JPYB/TdvG+2GY0A7reOwEmcYqJi0Z3XAYaDLH7OfEtgL8p5VEix2h9HJarsXYAMfvjY0c9jY\n J6BjtgWx2AVm+tu26+wDU2kRyR60IxiyriF26EEwfKd+WxUMxk0rz5aOwL6g7Qxg6XCYM7/j\n 22jATjAy78yGcIKS9nKCpYVw64aIVfvDVNF9tGO70TRJFiOxZlc1za46ml11NP99axDZgNyZ\n dHWynFEHKpkr/mpZsjpdKfePS0l+irb+kWmzf6kDrbyPNSBMIbGjcPG2m1TElWWos5INCChC\n 7Co8/sYUIxLGy7KuMqoUqSpdwagNaC9Fit2FR2qnL4mwXJbGJDFMKqPa2XIoB48cdI774JMv\n ZzZi/XnuhQyL/nOAJ/P3iXZu0CL1k8dmf5cox/NA0ayPLlB1lnm3xhkfaQ6UjbfRDX3XMoO/\n eBV4nao9HR7ycWSiazDKtWetSru/Mk9nqd3Tp0krHq/UbQbRUc73ZHP4wFlrts/o74Xyk2mR\n ocVav4s5bo4L1TVnxsSkOkEWeJBQqWX/AMnqXmxDAwAA", "\n H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsVy+t/xu7r5k0XjDXruKVn8evOA3WL7ii42\n i3eftjNZ3Nl7mt2isf8bi8XMpy3sFocmZ1ucWd7D7MDhsWbeGkaPXwuWsnos3vOSyeP611es\n Hu/3XWULYI3SsynKLy1JVcjILy6xVYo2tDDSM7S00DMysdQzNDaPtTIyVdK3s0lJzcksSy3S\n t0vQy9hweAtLwT65ivY/B9gaGKdIdDFyckgImEj8PrmWvYuRi0NIYCmjxOVTKxm7GDmAEjIS\n Hy4JQNQIS/y51sUGUfOaUeL+4aVMIAlhAVeJE3/PgNkiAvYSn6+cZgIpYhaYxCjxr3MBK0TH\n ZEaJk2/Ws4NUsQnYShyZ+ZUVxOYVcJNYvreLCWQbi4CqxN7niiBhUYE4ieVb5rNDlAhKnJz5\n hAXE5hRwkNjecgeslVnATGLe5ofMELa8RPPW2VC2uMStJ/OZJjAKzULSPgtJyywkLbOQtCxg\n ZFnFKJJaWpybnltspFecmFtcmpeul5yfu4kRGH/bjv3csoOx613wIUYBDkYlHt4P3aLxQqyJ\n ZcWVuYcYJTiYlUR4nc6ejhPiTUmsrEotyo8vKs1JLT7EaAr020RmKdHkfGBqyCuJNzQ1NLew\n NDQ3Njc2s1AS5+0QOBgjJJCeWJKanZpakFoE08fEwSnVwHh1Z+W1oFPK77n597wL/xT96Zj1\n zpvVR/sWPfz3p21r+/k/jTpsr2KmNJ989eZ/r4zHJ4VFGxz+lpxbcPzx6hKpE6t/uLzMendj\n 6/lq5pUWDuk35KK+/s+qjFs34eaXvb9aXtYLa95yOvP98CPzK0YXr06UMg6O6Ev5IuJwJW+P\n ssuxA0LtjSu9lFiKMxINtZiLihMBmu1j9NUCAAA=" ], "X-CMS-MailID": "20200720125159eucas1p217be2baca613a022ae05d6ba59c6e1eb", "X-Msg-Generator": "CA", "Content-Type": "text/plain; charset=\"utf-8\"", "X-RootMTR": "20200720120850eucas1p10debcafa273d244a7e63d225c50cc9df", "X-EPHeader": "CA", "CMS-TYPE": "201P", "X-CMS-RootMailID": "20200720120850eucas1p10debcafa273d244a7e63d225c50cc9df", "References": "\n <CGME20200720120850eucas1p10debcafa273d244a7e63d225c50cc9df@eucas1p1.samsung.com>\n <20200720120938.34660-1-harry.van.haaren@intel.com>", "Subject": "Re: [dpdk-dev] [PATCH] service: fix stop API to wait for service\n\tthread", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116314, "web_url": "https://patches.dpdk.org/comment/116314/", "msgid": "<BYAPR11MB31434ED0846748546D905F86D77B0@BYAPR11MB3143.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB31434ED0846748546D905F86D77B0@BYAPR11MB3143.namprd11.prod.outlook.com", "date": "2020-07-20T14:20:22", "subject": "Re: [dpdk-dev] [PATCH] service: fix stop API to wait for service\n\tthread", "submitter": { "id": 317, "url": "https://patches.dpdk.org/api/people/317/?format=api", "name": "Van Haaren, Harry", "email": "harry.van.haaren@intel.com" }, "content": "> -----Original Message-----\n> From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>\n> Sent: Monday, July 20, 2020 1:52 PM\n> To: Van Haaren, Harry <harry.van.haaren@intel.com>; dev@dpdk.org\n> Cc: david.marchand@redhat.com; igor.romanov@oktetlabs.ru;\n> honnappa.nagarahalli@arm.com; Yigit, Ferruh <ferruh.yigit@intel.com>;\n> nd@arm.com; aconole@redhat.com\n> Subject: Re: [PATCH] service: fix stop API to wait for service thread\n> \n> \n> W dniu 20.07.2020 o 14:09, Harry van Haaren pisze:\n> > This commit improves the service_lcore_stop() implementation,\n> > waiting for the service core in question to return. The service\n> > thread itself now has a variable to indicate if its thread is\n> > active. When zero the service thread has completed its service,\n> > and has returned from the service_runner_func() function.\n> >\n> > This fixes a race condition observed in the DPDK CI, where the\n> > statistics of the service were not consistent with the expectation\n> > due to the service thread still running, and incrementing a stat\n> > after stop was called.\n> >\n> > Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>\n> >\n> > ---\n> >\n> > This is one possible solution, that avoids a class of race-conditions\n> > based on stop() api and following behaviours. Without a change in\n> > implementation of the service core thread, we could not detect when\n> > the thread was actually finished. This is now possible, and the stop\n> > api makes use of it to wait for 1000x one millisecond, or log a warning\n> > that a service core didn't return quickly.\n> >\n> > Thanks for the discussion/debug on list - I'm not sure how to add\n> > reported-by/suggested-by etc tags: but I'll resend a V2 (or can add\n> > on apply).\n> >\n> > ---\n> > lib/librte_eal/common/rte_service.c | 24 ++++++++++++++++++++++++\n> > 1 file changed, 24 insertions(+)\n> >\n> > diff --git a/lib/librte_eal/common/rte_service.c\n> b/lib/librte_eal/common/rte_service.c\n> > index 6a0e0ff65..d2255587d 100644\n> > --- a/lib/librte_eal/common/rte_service.c\n> > +++ b/lib/librte_eal/common/rte_service.c\n> > @@ -65,6 +65,7 @@ struct core_state {\n> > \t/* map of services IDs are run on this core */\n> > \tuint64_t service_mask;\n> > \tuint8_t runstate; /* running or stopped */\n> > +\tuint8_t thread_active; /* indicates when the thread is in service_run() */\n> > \tuint8_t is_service_core; /* set if core is currently a service core */\n> > \tuint8_t service_active_on_lcore[RTE_SERVICE_NUM_MAX];\n> > \tuint64_t loops;\n> > @@ -457,6 +458,8 @@ service_runner_func(void *arg)\n> > \tconst int lcore = rte_lcore_id();\n> > \tstruct core_state *cs = &lcore_states[lcore];\n> >\n> > +\t__atomic_store_n(&cs->thread_active, 1, __ATOMIC_RELAXED);\n> > +\n> > \t/* runstate act as the guard variable. Use load-acquire\n> > \t * memory order here to synchronize with store-release\n> > \t * in runstate update functions.\n> > @@ -475,6 +478,7 @@ service_runner_func(void *arg)\n> > \t\tcs->loops++;\n> > \t}\n> >\n> > +\t__atomic_store_n(&cs->thread_active, 0, __ATOMIC_RELAXED);\n> > \treturn 0;\n> > }\n> >\n> > @@ -765,6 +769,26 @@ rte_service_lcore_stop(uint32_t lcore)\n> > \t__atomic_store_n(&lcore_states[lcore].runstate, RUNSTATE_STOPPED,\n> > \t\t__ATOMIC_RELEASE);\n> >\n> > +\t/* wait for service lcore to return */\n> > +\ti = 0;\n> > +\tuint8_t active;\n> > +\tuint64_t start = rte_rdtsc();\n> > +\tdo {\n> > +\t\tactive = __atomic_load_n(&lcore_states[lcore].thread_active,\n> > +\t\t\t\t\t __ATOMIC_RELAXED);\n> > +\t\tif (active == 0)\n> > +\t\t\tbreak;\n> > +\t\trte_delay_ms(1);\n> > +\t\ti++;\n> > +\t} while (i < 1000);\n> > +\n> > +\tif (active != 0) {\n> > +\t\tuint64_t end = rte_rdtsc();\n> > +\t\tRTE_LOG(WARNING, EAL,\n> > +\t\t\t\"service lcore stop() failed, waited for %ld cycles\\n\",\n> > +\t\t\tend - start);\n> > +\t}\n> > +\n> > \treturn 0;\n> > }\n> >\n> I don't like the idea of inserting this polling loop inside API call.\n> And I don't like setting up a 1000 iterations constraint.\n> How about keeping the thread_active flag, but moving checking state of\n> this flag to separate function. This way the user of the API would be\n> able to write own loop.\n> Maybe he/she would like a custom loop, because:\n> * waiting for more cores\n> * would like to wait longer\n> * would like to check if service is finished less often...\n\nAgree - good feedback, thanks. v2 on the way, with this approach.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 2ADD3A0527;\n\tMon, 20 Jul 2020 16:20:36 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 095101DBB;\n\tMon, 20 Jul 2020 16:20:36 +0200 (CEST)", "from mga17.intel.com (mga17.intel.com [192.55.52.151])\n by dpdk.org (Postfix) with ESMTP id C13431AFB\n for <dev@dpdk.org>; Mon, 20 Jul 2020 16:20:33 +0200 (CEST)", "from fmsmga008.fm.intel.com ([10.253.24.58])\n by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 20 Jul 2020 07:20:32 -0700", "from orsmsx109.amr.corp.intel.com ([10.22.240.7])\n by fmsmga008.fm.intel.com with ESMTP; 20 Jul 2020 07:20:32 -0700", "from orsmsx156.amr.corp.intel.com (10.22.240.22) by\n ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Mon, 20 Jul 2020 07:20:31 -0700", "from ORSEDG002.ED.cps.intel.com (10.7.248.5) by\n ORSMSX156.amr.corp.intel.com (10.22.240.22) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Mon, 20 Jul 2020 07:20:31 -0700", "from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.103)\n by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Mon, 20 Jul 2020 07:20:30 -0700", "from BYAPR11MB3143.namprd11.prod.outlook.com (2603:10b6:a03:92::32)\n by BYAPR11MB3383.namprd11.prod.outlook.com (2603:10b6:a03:1b::32)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.25; Mon, 20 Jul\n 2020 14:20:23 +0000", "from BYAPR11MB3143.namprd11.prod.outlook.com\n ([fe80::9c6b:5ce:b551:8678]) by BYAPR11MB3143.namprd11.prod.outlook.com\n ([fe80::9c6b:5ce:b551:8678%4]) with mapi id 15.20.3195.023; Mon, 20 Jul 2020\n 14:20:23 +0000" ], "IronPort-SDR": [ "\n cg78lQrFCMNosdcgrGuOxAeuKHa5hZx9XPCVX9eR5+DFayJQ5EGGJuhrDIt4ipUKpgaioFs5ql\n 1uG4CKZqOqgA==", "\n glTqT+XFpgF19RDXyyurxcNnOg4sz5898z2ImZ7DqQpaliGy064vprV1MGrNjTJ0K57K3R3YjE\n 06Xra9ajdVOg==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9687\"; a=\"129996166\"", "E=Sophos;i=\"5.75,375,1589266800\"; d=\"scan'208\";a=\"129996166\"", "E=Sophos;i=\"5.75,375,1589266800\"; d=\"scan'208\";a=\"271443361\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=EEy922qB8jmBJfKr0v+jvtn2flvP70TGW1hJjmQ1lEKfiy4WyEVfdFDoiyVrI1GFLRN8H5V7cd0+FByAvPIc5SZosFnNbX2JgWT7TbOtpScXTMmzLEYvcl9iXTDgLhaN5XsdAuLE5oKE6IYdBmvnQjYuuEbeE33PWMxt8EpS9x8TpHnCZXv9aQ2+efbWjZHLPPfW7YRvLG1rlUpCM9OcH8HQc+5lrMk6jN2onlaIwVRxJ85RM2LJWXwcQlZbAuoX3dGhI8B6LOERgLs4lcWJr9Sdf0ZR+lFOo3yVTH17s65VPi4LTtCu0O35J8Po0wlgrT8/rtki0STSQVtrL4Uagw==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=GldZsvCFmZwgE2fRR2ca/AvUfx63Gh/xwGEaohaFMn0=;\n b=OvtAvlxR5ICwwQas9YWyBN3zCtQQbhIN8exfatIirfy1YoYc9QHNPvh1suwndmVQz4maqhtTcvVIa1hJMtGcpj5g9cfXJ9r3IL63JrmIw/q3AowrUEzpmSNYrxYIoZfOg1uLH2osj+ygZtY34t5TeYFIzK4asw4PYNUJjnSVJqRuB/4AbKfag1bMGGOfefXJLC/hGPy7xoT5Gx2FRvrScDBP7gUo/zrtmBgIDOOrO3o4eEkdhMlS+au3v9FhHQD5rP0KzxelXslmHYcDrcYHV4yDd2jXiAmJyzMUHpgi1BXMgv5SyR/Vl2v1LMTDcibXVVnDFsye2Dz2j7jE1ruKvQ==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=GldZsvCFmZwgE2fRR2ca/AvUfx63Gh/xwGEaohaFMn0=;\n b=Je/bigY6JziotfnKgXPokbgkq5aPsLJjTlW3E5tqoopTebtcb+6/rAVDs4c/MsP4DR9LzMQjqFRcMDVH5PKjxu5j/Ymshe9jGrpjTTzdl9RHWXz/xlOtX3QSF0EKYb+YlKaNkUbi130ph3Xn5ZQ089JHG75TXm4L1Yarr6GYWgg=", "From": "\"Van Haaren, Harry\" <harry.van.haaren@intel.com>", "To": "Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>, \"dev@dpdk.org\"\n <dev@dpdk.org>", "CC": "\"david.marchand@redhat.com\" <david.marchand@redhat.com>,\n \"igor.romanov@oktetlabs.ru\" <igor.romanov@oktetlabs.ru>,\n \"honnappa.nagarahalli@arm.com\" <honnappa.nagarahalli@arm.com>, \"Yigit,\n Ferruh\" <ferruh.yigit@intel.com>, \"nd@arm.com\" <nd@arm.com>,\n \"aconole@redhat.com\" <aconole@redhat.com>", "Thread-Topic": "[PATCH] service: fix stop API to wait for service thread", "Thread-Index": "AQHWXo6I/ww/bGWdo0WQaD5tUa2YuKkQa/wAgAADINA=", "Date": "Mon, 20 Jul 2020 14:20:22 +0000", "Message-ID": "\n <BYAPR11MB31434ED0846748546D905F86D77B0@BYAPR11MB3143.namprd11.prod.outlook.com>", "References": "\n <CGME20200720120850eucas1p10debcafa273d244a7e63d225c50cc9df@eucas1p1.samsung.com>\n <20200720120938.34660-1-harry.van.haaren@intel.com>\n <fbd9c539-24c1-8cd8-988f-56dd423f892d@partner.samsung.com>", "In-Reply-To": "<fbd9c539-24c1-8cd8-988f-56dd423f892d@partner.samsung.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-product": "dlpe-windows", "dlp-reaction": "no-action", "dlp-version": "11.2.0.6", "authentication-results": "partner.samsung.com; dkim=none (message not signed)\n header.d=none;partner.samsung.com; dmarc=none action=none\n header.from=intel.com;", "x-originating-ip": "[87.198.126.230]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "a33ebc19-eea0-4460-dcc5-08d82cb80a3e", "x-ms-traffictypediagnostic": "BYAPR11MB3383:", "x-ld-processed": "46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BYAPR11MB33831329A0AFF31CA991C39CD77B0@BYAPR11MB3383.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n WHoL8VJvAHe2F0sfY7s3mVyFkE3PdEydf2SG6x8v8GVwz7mo/rOpUJsHclxWzy2BTPDhvuNdv0zn2mchXPk0FT1FqvDXioPhdfmooOH1anr1LLysTS+e1DYoHfAbinqqV+5zx6PPm4SgBnV+D+JGUXd8C5Yveq89mfS/AhpyoASSX35odF9bSOQmT7Q3ICD1NZjgBEdzGnQ5AtoCuXu1tY8T/+hJbAwA+oA8gYNVe+vsZ//Slts/JBiXgq5wC1bw7OysrBfPRAa3G1rhW0+QU2vn5MBq/4fo8vJOXL4yMQeaB87ICqvBNJkcKdfn7auUCzDu0Gk8kL+FP9IeiupOD4xIwO3xom5JWpt8lyjeihDvbCdMO4EIyWKIC+E6nDQ0", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB3143.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(396003)(39860400002)(376002)(346002)(366004)(136003)(110136005)(52536014)(478600001)(54906003)(5660300002)(33656002)(26005)(4326008)(186003)(53546011)(83380400001)(6506007)(66446008)(71200400001)(7696005)(9686003)(66946007)(66476007)(66556008)(64756008)(76116006)(316002)(2906002)(8676002)(8936002)(86362001)(55016002)(87944003);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n VA5kHx1JQkkFDgzUHFdef1CZLmTOuCkDMP4miMarZO/IUK1pDm1uTYo2WYY31wQRGKruEtMwnwsLR2ex6QX3czH+afjlmm17zR9sRsRU3NNmLCAj5+/WxH8kdduDD9/3XIH9zY8VooxNT2y33FNx6d+yYRp+NMKFYrAdgs1Qqw89Au2bZBYWn1h4HRBydBIskY4Y5ClUYrzKsGr2Hnkvwp2TFLHkGOE76yz5cllxiJAMi35et6wNN3nTz/V2i1gu//maeSqkWwlJvFDqddNKhe+kJvpeKL/iTkHMj/QWTW0zx+jS201LoHlBJwSCq7DJq/Wp1X1RFYOQXPbpKy3Tvb5zeehkxn+RscXLhm4UlazzAq2nauzmkLwLAN+4haLDNx88Ngu3PQeTCzccsRAYl9pCe32MyedmHRwPpuJnePqzZVGNBGke8m8LG9672qL5X4kL2iOJEughxBfk5vCh6aMRAky8EgNW2PWGOv/yqF92Cl4LlD6o5lMoRpUp286A", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-AuthAs": "Internal", "X-MS-Exchange-CrossTenant-AuthSource": "BYAPR11MB3143.namprd11.prod.outlook.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "\n a33ebc19-eea0-4460-dcc5-08d82cb80a3e", "X-MS-Exchange-CrossTenant-originalarrivaltime": "20 Jul 2020 14:20:22.9292 (UTC)", "X-MS-Exchange-CrossTenant-fromentityheader": "Hosted", "X-MS-Exchange-CrossTenant-id": "46c98d88-e344-4ed4-8496-4ed7712e255d", "X-MS-Exchange-CrossTenant-mailboxtype": "HOSTED", "X-MS-Exchange-CrossTenant-userprincipalname": "\n eEUHr/wTrRlA9aIE8H8JC8MOF7vJFWE5V34L7m9ZrWeeNV0T5bpn1RffQThoRCdSuLONhPkS35uHMlt6KExQ5yrpzlu14ipMpzj4HgJX5IY=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR11MB3383", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [PATCH] service: fix stop API to wait for service\n\tthread", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]