From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id E07BB1B173 for ; Wed, 20 Dec 2017 12:21:42 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2017 03:21:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,431,1508828400"; d="scan'208";a="15146577" Received: from silpixa00398672.ir.intel.com ([10.237.223.128]) by fmsmga001.fm.intel.com with ESMTP; 20 Dec 2017 03:21:41 -0800 From: Harry van Haaren To: dev@dpdk.org Cc: Harry van Haaren Date: Wed, 20 Dec 2017 11:21:47 +0000 Message-Id: <1513768907-112647-2-git-send-email-harry.van.haaren@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1513768907-112647-1-git-send-email-harry.van.haaren@intel.com> References: <1513768907-112647-1-git-send-email-harry.van.haaren@intel.com> Subject: [dpdk-dev] [PATCH 2/2] service: fix service core launch 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: , X-List-Received-Date: Wed, 20 Dec 2017 11:21:43 -0000 This patch fixes a potential bug, which was not consistently showing up in the unit tests. The issue was that the service- lcore being started was not in a "WAIT" state, and hence EAL would return -EBUSY instead of launching the lcore. In order to ensure a core is in a launch-ready state, the application must call rte_eal_wait_lcore, to ensure that the core has completed its previous task, and that EAL is ready to re-launch it. The call to rte_eal_wait_lcore() is explicitly not in the service core function, to make it visible to the application. Requiring an explicit function call ensures the developer sees that a lcore could block in the rte_eal_wait_lcore() function if the core hasn't returned from its previous function. >>From a usability perspective, hiding the wait_lcore() inside service cores would cause confusion. This patch adds rte_eal_wait_lcore() calls to the unit tests, to ensure that the lcores for testing functionality are ready to run the test. Fixes: 21698354c832 ("service: introduce service cores concept") +CC stable@dpdk.org Signed-off-by: Harry van Haaren --- @Stable maintainers; this is an EXPERIMENTAL tagged API, so I'm not sure what the expectation is in terms of backporting. --- lib/librte_eal/common/include/rte_service.h | 4 +++- test/test/test_service_cores.c | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h index 9272440..495b531 100644 --- a/lib/librte_eal/common/include/rte_service.h +++ b/lib/librte_eal/common/include/rte_service.h @@ -274,7 +274,9 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id, * Start a service core. * * Starting a core makes the core begin polling. Any services assigned to it - * will be run as fast as possible. + * will be run as fast as possible. The application must ensure that the lcore + * is in a launchable state: e.g. call *rte_eal_lcore_wait* on the lcore_id + * before calling this function. * * @retval 0 Success * @retval -EINVAL Failed to start core. The *lcore_id* passed in is not diff --git a/test/test/test_service_cores.c b/test/test/test_service_cores.c index 311c704..43f2318 100644 --- a/test/test/test_service_cores.c +++ b/test/test/test_service_cores.c @@ -348,6 +348,7 @@ service_lcore_en_dis_able(void) /* call remote_launch to verify that app can launch ex-service lcore */ service_remote_launch_flag = 0; + rte_eal_wait_lcore(slcore_id); int ret = rte_eal_remote_launch(service_remote_launch_func, NULL, slcore_id); TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed."); @@ -505,6 +506,10 @@ service_threaded_test(int mt_safe) if (!mt_safe) test_params[1] = 1; + /* wait for lcores before start() */ + rte_eal_wait_lcore(slcore_1); + rte_eal_wait_lcore(slcore_2); + rte_service_lcore_start(slcore_1); rte_service_lcore_start(slcore_2); @@ -611,6 +616,7 @@ service_app_lcore_poll_impl(const int mt_safe) rte_service_runstate_set(id, 1); uint32_t app_core2 = rte_get_next_lcore(slcore_id, 1, 1); + rte_eal_wait_lcore(app_core2); int app_core2_ret = rte_eal_remote_launch(service_run_on_app_core_func, &id, app_core2); -- 2.7.4