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 52121A04DD for ; Wed, 27 Nov 2019 21:11:53 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 068881BEA7; Wed, 27 Nov 2019 21:11:53 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 1D1181BEA7 for ; Wed, 27 Nov 2019 21:11:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574885511; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VsXr4iic9KLJW4XW+ClMII5+S7HscDM5xBXDri2nuzI=; b=EI5i746GQFeG3w7NESsnoG8nYTJqnx5PnbjJ65TzDtcs8U1jtxvekpvI+NS/Z/SUWGLH4R IKJwmqTzx3wXUOIH8jFaEyTfIIXSyke/JTvZD8TCN/K0aogTW0yxLB3xQmBHZ4P2ZR8XMl 2W4IJNMH+EudquZu6kp/JWm+0ybqPfw= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-359-Xdw5B62pMk-WVRkNhqXeJQ-1; Wed, 27 Nov 2019 15:11:49 -0500 Received: by mail-vs1-f69.google.com with SMTP id b3so3288617vse.18 for ; Wed, 27 Nov 2019 12:11:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MlJbmTMN6dsVOUoF6ibso85YUN2qe1QqlO+G95ZtekY=; b=PZ50bzpkzbTBycQhHy11PqQjdZrn68rp1TuzZNLdZH/eKY6Y+p5kSTJWS1LQ0bZLC7 p16wvWRHJKQudgnFKSMjG7ZZgt6jYhcJoAh0zXDgQBLZPGPR7akWLU+xWToD0yHkgple q+XYb9+Xxq/DIeSRxnaAA/1s6D0Dbav2//2Fb5tVz4bN3Dw9FApJ/YpJmdgEC08+ok6c x6P7PXiXB+mjRJmC302Xm9tLnJjClAQNWaZOSg8QxUU4jfqVFrjDujtGH4e6kDJUW6X3 GQOAkXm+RZkSyLDfPQA26SJ/P4xpPcw2kungliRTyariLeQHnuB095GLOixbeBVytXbA 94KA== X-Gm-Message-State: APjAAAXxOMwCHl3cdVNpl0h5+pypwZr13fBCrfgxajxsUgH18kuvSR0j OdA5KU1M4FUZp3mUPMMZWWFMRcnYGkqqxqaXHloKKEH1AP47cjazRegmgKplT0KxU6hfN9GqkW0 D/ZFRjh95d4fooyJr26jUBXE= X-Received: by 2002:a1f:5681:: with SMTP id k123mr2155986vkb.39.1574885509274; Wed, 27 Nov 2019 12:11:49 -0800 (PST) X-Google-Smtp-Source: APXvYqzTaZuEDroccdlw8kpKd4rwpmwTfjKBbTfNRRBT8Didi6QVGfWVP982fGjfzILc8XwQH63fcPGojWlRgE9JbP8= X-Received: by 2002:a1f:5681:: with SMTP id k123mr2155952vkb.39.1574885508808; Wed, 27 Nov 2019 12:11:48 -0800 (PST) MIME-Version: 1.0 References: <20191127132027.80239-1-harry.van.haaren@intel.com> In-Reply-To: From: David Marchand Date: Wed, 27 Nov 2019 21:11:37 +0100 Message-ID: To: "Van Haaren, Harry" Cc: Aaron Conole , "dev@dpdk.org" , "stable@dpdk.org" X-MC-Unique: Xdw5B62pMk-WVRkNhqXeJQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-stable] [PATCH] test/service: fix wait for service core X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Wed, Nov 27, 2019 at 3:16 PM Van Haaren, Harry wrote: > > > -----Original Message----- > > From: Aaron Conole > > Sent: Wednesday, November 27, 2019 2:10 PM > > To: Van Haaren, Harry > > Cc: dev@dpdk.org > > Subject: Re: [PATCH] test/service: fix wait for service core > > > > Harry van Haaren writes: > > > > > This commit fixes a sporadic failure of the service_autotest > > > unit test, as seen in the DPDK CI. The failure occurs as the main tes= t > > > thread did not wait on the service-thread to return, and allowing it > > > to read a flag before the service was able to write to it. > > > > > > The fix changes the wait API call to specific the service-core ID, > > > and this waits for cores with both ROLE_RTE and ROLE_SERVICE. > > > > > > The rte_eal_mp_wait_lcore() call does not (and should not) wait > > > for service cores, so must not be used to wait on service-cores. > > > > > > Fixes: f038a81e1c56 ("service: add unit tests") > > > > > > Reported-by: Aaron Conole > > > Signed-off-by: Harry van Haaren > > > > > > --- > > > > It might also be good to document this behavior in the API area. It's > > unclear that the lcore wait function which takes a core id will work, > > but the broad wait will not. > > Yes agreed that docs can improve here - different patch. > > > > > Given this is a fix in the unit test, and not a functional change > > > I'm not sure its worth backporting to LTS / stable releases? > > > I've not added stable on CC yet. > > > > I think it's worth it if the LTS / stable branches use the unit tests > > (otherwise, they will observe sporadic failures). > > Ok, I've added stable@dpdk.org on CC now > > > > > app/test/test_service_cores.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/app/test/test_service_cores.c b/app/test/test_service_co= res.c > > > index 9fe38f5e0..a922c7ddc 100644 > > > --- a/app/test/test_service_cores.c > > > +++ b/app/test/test_service_cores.c > > > @@ -483,7 +483,7 @@ service_lcore_en_dis_able(void) > > > int ret =3D rte_eal_remote_launch(service_remote_launch_func, NUL= L, > > > slcore_id); > > > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed."= ); > > > - rte_eal_mp_wait_lcore(); > > > + rte_eal_wait_lcore(slcore_id); > > > TEST_ASSERT_EQUAL(1, service_remote_launch_flag, > > > "Ex-service core function call had no effect."); > > > > Should we also have some change like the following (just a guess): > > > > diff --git a/app/test/test_service_cores.c b/app/test/test_service_core= s.c > > index 9fe38f5e08..695c35ac6c 100644 > > --- a/app/test/test_service_cores.c > > +++ b/app/test/test_service_cores.c > > @@ -773,7 +773,7 @@ service_app_lcore_poll_impl(const int mt_safe) > > > > /* flag done, then wait for the spawned 2nd core to return */ > > params[0] =3D 1; > > - rte_eal_mp_wait_lcore(); > > + rte_eal_wait_lcore(app_core2); > > > > /* core two gets launched first - and should hold the service loc= k */ > > TEST_ASSERT_EQUAL(0, app_core2_ret, > > > I reviewed this usage of the function, and I believe it waits on applicat= ion > cores (aka, ROLE_RTE, not ROLE_SERVICE). Hence this usage is actually cor= rect. > Please review and double check my logic though - more eyes is good. It seems to be the case, yes. My overall feeling is that the services stuff is a giant hack, so better documentation will prove me wrong :-). As I said I am for taking this change in 19.11 now, as it only impacts this test and it seems to solve the random failures. Acked-by: David Marchand --=20 David Marchand