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 3EA8EA04DD; Wed, 27 Nov 2019 19:11:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D8F201BEA7; Wed, 27 Nov 2019 19:11:42 +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 0C08A1BE9A for ; Wed, 27 Nov 2019 19:11:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574878300; 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=wQZ5wNs/EZD6rlAa8aFOWQK9JPPX1VvM+zbDN4yqYe4=; b=IIDlnnsV84VXEZU6SAkA1iiPe7GEaU/PFwMn/CgbZ2uu1y/kDA/okLBmAEPZkpfgn4gWRF JWwbmrY6joRFk3uX2Jirb6+jYKPhQnAlnrXabzYbuJ2csyF4a7RMYp8yMwp+9O19MQ1iKv M+SmgHX6nImdwCyL4zy6em0dFVli/JM= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-63-pvbjihwTN1yFhPl2HhwDDQ-1; Wed, 27 Nov 2019 13:11:38 -0500 Received: by mail-ua1-f72.google.com with SMTP id o17so4203107uar.8 for ; Wed, 27 Nov 2019 10:11:38 -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=CZmnN1UhYYPM9EHPY1k2qxDZoHM2ZZQrH3WwL3a7wm4=; b=nMvLMp8RuSUsppP+TY9gyBOOKPKGtE4lk57BUvWgRBlOz8t0VRVYK11Uzd0Vllpemi 0NVYDZp4le2gj3cNZDMkU4aXPrAfy3hzK1CBfrgbQc7TzHDZ3bM/aXanTISSCWrAPMC3 kx2YdXYVcSYNC+xvzxOSD3A7di2jislxwO1edRxcQNEG0wQJAKKuWu/Ax7jjiZBD6r8h ZbmtM4BIE5GebIZvsrqFNAD4djL9wDcxhxpcqGXvWHiQ11OX0ipbsydd3mmal3dOhhJ8 Zw6YjL1mvXvbzr7wObOO5UuJQVydTLOTE9e3vDWvqBF9kKxHAfhixuUIDzgz0M3UML/5 lxKA== X-Gm-Message-State: APjAAAUFO2mhF45irTCUna0vOD6hsWZN356Bw+mRbQWZP9sLyggio4kf ztp5DzBtVDG7e6tQNDXG1y/iQRcd0zMfuwN/FmpNqclFu2nHD3kDhX+oHMHSZId+JqEINim3SDD g1+pWG2SCQU+M34yp7BE= X-Received: by 2002:a1f:60ce:: with SMTP id u197mr3819756vkb.80.1574878297776; Wed, 27 Nov 2019 10:11:37 -0800 (PST) X-Google-Smtp-Source: APXvYqygmm3uaECmlIeO3vWTqe1bxHxuXFOP4BLkFLwSZs6Hh9FyyVCgwI0Jh8ENZwFWOpS0cr3A2804w9e+enj6HRk= X-Received: by 2002:a1f:60ce:: with SMTP id u197mr3819724vkb.80.1574878297282; Wed, 27 Nov 2019 10:11:37 -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 19:11:26 +0100 Message-ID: To: "Van Haaren, Harry" , Aaron Conole Cc: "dev@dpdk.org" , "stable@dpdk.org" X-MC-Unique: pvbjihwTN1yFhPl2HhwDDQ-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. > 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? --=20 David Marchand