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 5AB5BA04DD; Wed, 27 Nov 2019 20:10:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 641521BEAF; Wed, 27 Nov 2019 20:10:26 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 6A1A61BEA7 for ; Wed, 27 Nov 2019 20:10:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574881824; 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=XCYmQCP7fWvVQ0GYNst3Kj6ZlzFXcA1hr9JDT7cC79I=; b=jWhD2823iVKBW7pXuknQtTU2psijOogxGJB8pS/kgGdGmMBIseGySC2ckMM/cXk21eR2Hm LwWil+u5JlN7iHcRl5D+EB4KUi3iXr5EGBI7ZyB8F+ohbB9heVZlfHj8KPMlPlTVXKWTBw 5HNaS1bV4RTQ+sk1MfWWk1H0qSfIInU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-209-UfKiGCPCMTaZ-xri07dk9A-1; Wed, 27 Nov 2019 14:10:21 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 91707800D4C; Wed, 27 Nov 2019 19:10:20 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-124-43.rdu2.redhat.com [10.10.124.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 39CEC5D6C8; Wed, 27 Nov 2019 19:10:17 +0000 (UTC) From: Aaron Conole To: David Marchand Cc: "Van Haaren\, Harry" , "dev\@dpdk.org" , "stable\@dpdk.org" References: <20191127132027.80239-1-harry.van.haaren@intel.com> Date: Wed, 27 Nov 2019 14:10:16 -0500 In-Reply-To: (David Marchand's message of "Wed, 27 Nov 2019 19:11:26 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: UfKiGCPCMTaZ-xri07dk9A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] test/service: fix wait for service core 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" David Marchand writes: > 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 te= st >> > > 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_c= ores.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, NU= LL, >> > > 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_cor= es.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 lo= ck */ >> > TEST_ASSERT_EQUAL(0, app_core2_ret, >> >> >> I reviewed this usage of the function, and I believe it waits on applica= tion >> cores (aka, ROLE_RTE, not ROLE_SERVICE). Hence this usage is actually co= rrect. >> Please review and double check my logic though - more eyes is good. >> > > I will check it later tonight but I am for taking this in 19.11 if we > can get more stable tests. > Aaron, do you have an objection? No objection