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 A061AA04DD; Wed, 27 Nov 2019 21:11:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 36ECC1BEB1; Wed, 27 Nov 2019 21:11:55 +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 C07F91BEAF for ; Wed, 27 Nov 2019 21:11:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574885513; 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=XCf8AHtiH1+fVr0XUQCpPyxnRlquVi93hExqoiawKHBEqKMUWumJUexKenduPj/AGRCPl6 cGujpd3kdjXqICkZyfjFCorx/+5Ad7uQjmJdnuEbXIUJ+bCgTEeP2Mf9kp5+niOfRVSIpx 3r9d3DG9XfCCRsO5Af9cFR5JGZqmpi0= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-369-SWxNclySMZylfVj4LDPzpg-1; Wed, 27 Nov 2019 15:11:49 -0500 Received: by mail-ua1-f70.google.com with SMTP id c12so4294550uap.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=hm0vU1iSO06qOtlGLVzIWSZRmOtBMhykefO3q5z/9YI+dtR4Xg/qWCUnI7qsem2lK/ QhErsY0nqtO6y/yHndMlTe09FYFCSZKT69fs6ubHxfw7/pQQqL8oodYpZt7KFK0RkQXG P644PvVf0PlozGVSpXbIrk7dGzLFN2RALRkDL1fx1Z7ZKEHCpkktGfQ138aAPiT7S5qP SeK4zaxr2U6Uvk2+UTTeN5IGx7qEFaH4w80Tyo0tFBy9iVheOUL4pVXikDuhgAp2hShc VTcpTmoazQR8/6RcBrBvfSNOQbwewaJ0DHPMA7fjG/4d8dN6OJeTkJVkoJU0zj1f2iUa H05g== X-Gm-Message-State: APjAAAWmU6FyougSpzKgTTgqJEOPCUWK+bGw++GW06xG702OuflmXSlf HWceDhxbepcR1T4WnSvoiyW/xfcRFhfQg3/+M9OxvDaNzSOXZhON5gkw+yIAEkvt6QI/+DLY7OU yg7S8BV7VE5URECnOzgA= X-Received: by 2002:a1f:5681:: with SMTP id k123mr2155985vkb.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: SWxNclySMZylfVj4LDPzpg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" 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" 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