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 E0804A04E0; Wed, 27 Nov 2019 12:37:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B3E7058C3; Wed, 27 Nov 2019 12:37:31 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id BACA25596 for ; Wed, 27 Nov 2019 12:37:29 +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 fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2019 03:37:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,249,1571727600"; d="scan'208";a="217369024" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga001.fm.intel.com with ESMTP; 27 Nov 2019 03:37:28 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 27 Nov 2019 03:37:28 -0800 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 27 Nov 2019 03:37:28 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.55) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 27 Nov 2019 03:37:28 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KcS/1UTdDpJ/cy4RaRtMoPBKzWysGOxNekucorzCF+MZTxbt2/WEcLy8DPZ5mEX2o9oz5iAqUB8v8fXkIKHSC/+l92XitTQdDxMs1N+aHFV2J2y+oRsSKfqBqUhIX5+0K2Dx4FKS+VIxI4UUD1GOaoZZQIUY2GE4ef+a6thtKQyTj5u3+iIKlb7P0O0tJx3TCkhAQCtC8vXJlNwDVJybsxk4ANvGAKBxVuLIbVNNX/hf0IGun0gyIa8OFJMpya61sIu9HM7y1cpOJZ+pgVWFX2eWzOUMPeK5/HB5oYc7NCMcWhsYqpy3pCMTHczN0vuToK22PVFOYvxrhuKvVex+qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rOKr4+jWWNveA1OoRHb+eRoNue1Rs2jStwBdm2SMoPk=; b=Jx2EnAKsrP0Ssg695MA7xK0MdmZNPB+V8bP4p8NIoL0d6EhLQ3javRC/AkS54jTGuOI80N2RoRUkTe3aqwIeyJ4O728BngiFna/18tn4apBCK+WAjd/SMLmIwP7hpuCcAfmUNzJ/Su/+fF3ZjmHVxrzQZt3BxC2bragO7BdLkZYiG/av7KhAsV6opdx/O2N6iELnUmqAm+5jZXjK7a4DVAc2r0BUIxcnvjdz9+ZAkAyHHGigdbSgzkEntHbvNspugmTDYJZWQFeXgP7PKtasrgeUPRW6m9K57+XrrzSD1LzgoDEgqXsri+0D3QZbwr/iFnivrED7Y+79GcG6GCVNng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rOKr4+jWWNveA1OoRHb+eRoNue1Rs2jStwBdm2SMoPk=; b=MWp7ahGip/BluLu1Jua0Xx+8+BXyeXOG0aRNT5hd83G7fch/Da+qOdprcyNYjVjidYUMcWy/XuJAeL42GN6PtPMc1/bpJKOjp1bKB91vwlLOUllcgJx6WWiypQ9/68Tt3LOqidN6gZsiUbwGUKHMwLCIxbG8Ss/3MUOQA1DD9Tg= Received: from MN2PR11MB4447.namprd11.prod.outlook.com (52.135.39.217) by MN2PR11MB3632.namprd11.prod.outlook.com (20.178.251.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Wed, 27 Nov 2019 11:37:23 +0000 Received: from MN2PR11MB4447.namprd11.prod.outlook.com ([fe80::c4e6:5cec:9c4c:e37]) by MN2PR11MB4447.namprd11.prod.outlook.com ([fe80::c4e6:5cec:9c4c:e37%2]) with mapi id 15.20.2474.023; Wed, 27 Nov 2019 11:37:23 +0000 From: "Van Haaren, Harry" To: Aaron Conole CC: Thomas Monjalon , "Amber, Kumar" , "dev@dpdk.org" , "Wang, Yipeng1" , "Yigit, Ferruh" , "Thakur, Sham Singh" , David Marchand Thread-Topic: [dpdk-dev] [PATCH v3] hash: added a new API to hash to query key id Thread-Index: AQHVoWHEOsXFPYPhH0ut+Ho/0A5KwqebvnSAgABPAACAABNGUoAAAEMwgAAO4wCAAATYEYAATxO8gADv7OCAAAP2oIAACJmngAFpGgA= Date: Wed, 27 Nov 2019 11:37:23 +0000 Message-ID: References: <20191122182100.15631-1-kumar.amber@intel.com> <2900799.QLPOietlla@xps> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzQ2ODk1YWEtNDc2NS00ZjY2LWI0OTQtNGZkOTc1OTA0M2I0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRjlXTDVqUGpvM1JlMlRSam1XcGhZTE9KZFpUUStsT3M2dFVZSHhNWWxsNWFZMStxVDdsaTdER2VqYVBlVlhwbSJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=harry.van.haaren@intel.com; x-originating-ip: [192.198.151.163] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27e59ee5-5f37-4a0e-4fcb-08d7732e2bc1 x-ms-traffictypediagnostic: MN2PR11MB3632: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(366004)(396003)(346002)(13464003)(199004)(189003)(6506007)(4326008)(74316002)(55016002)(5660300002)(25786009)(81166006)(66476007)(14454004)(76176011)(186003)(6246003)(33656002)(8936002)(256004)(14444005)(9686003)(52536014)(446003)(86362001)(66946007)(7696005)(81156014)(8676002)(2906002)(53546011)(3846002)(229853002)(316002)(102836004)(66066001)(99286004)(6436002)(478600001)(305945005)(6116002)(66446008)(66556008)(64756008)(76116006)(11346002)(71190400001)(71200400001)(26005)(6916009)(7736002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR11MB3632; H:MN2PR11MB4447.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o9OvrZ17YhRZWFqr2a5VEzYPjWEKJ6riLYg2bdgqAWMNbhLclSrmZZ+NC6G27af5TSACChaFQaE0E57Sclee11/htIWawOWzEFHZntJ8nA4RWZ9U2NE/mMM8sxtQpCSd5jGj3hwnVTCVHxkTg16Mjs6ZVBgMIwrhTnHbQguCSm0D8vKYwX4aaxFPoslpDfkR6ed8tTDR4fqiNSV/SZ8dLmCsp8eGlkFQxEpqkf8uxk6kKhvQ+ReMqZ3UITXYM4ChZsPDbJtlgJHqaaFD142LpNINrKKNef6GcYoIUzmrYPKyCLbNkuTsEMwaDACVWRUCiUQSxD3NMXVn1ATCXD3R4DhEZcC89iHsk17+hEKHVRBqrVUUVGPFke1GTvkLuaabkEiQ0mVK6h/BLf7q1/mrU5ScNeZD0UtUXmpPOCACh60RsenCYd4L/Ywf8/nvKOEt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 27e59ee5-5f37-4a0e-4fcb-08d7732e2bc1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2019 11:37:23.3445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yAXftkG6Ru6mysGWVmafDG7mV8U790RuBP17Ltp/StVSnNfbtD6Mrcd3qrllTRHtkZOYAR6v8gEewnEn1JA/SL61sDeEJy5vwaTadfFdVSE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3632 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3] hash: added a new API to hash to query key id 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" > -----Original Message----- > From: Aaron Conole > Sent: Tuesday, November 26, 2019 1:57 PM > To: Van Haaren, Harry > Cc: Thomas Monjalon ; Amber, Kumar > ; dev@dpdk.org; Wang, Yipeng1 > ; Yigit, Ferruh ; Thakur, > Sham Singh ; David Marchand > > Subject: Re: [dpdk-dev] [PATCH v3] hash: added a new API to hash to query > key id >=20 > "Van Haaren, Harry" writes: >=20 > >> -----Original Message----- > >> From: Van Haaren, Harry > >> Sent: Tuesday, November 26, 2019 1:19 PM > >> To: Aaron Conole ; Thomas Monjalon > > > > > > > > >> > EAL: Test assert service_lcore_en_dis_able line 487 failed: Ex-servi= ce > >> core > >> > function call had no effect. > >> > > >> > So I'll spend some time in this area, it seems. > >> > >> > >> The below diff makes it 100% reproducible here, failing every time. > >> > >> It seems like the main thread is returning, before the service thread = has > >> returned. > >> > >> The rte_eal_mp_wait_lcore() call seems to not wait on the service-core= , > >> which allows > >> the main thread to read the "service_remote_launch_flag" value as 0 > (before > >> the service-thread writes it to 1). > >> > >> Adding the delay between the service launch and service write being > >> performed makes this issue much much more likely to occur - so the abo= ve > >> description I have confidence in. > >> > >> What I'm not clear on (yet) is why the eal_mp_wait_lcore() isn't > waiting... > >> > >> -H > >> > >> > >> diff --git a/app/test/test_service_cores.c > b/app/test/test_service_cores.c > >> index 9fe38f5e0..846ad00d1 100644 > >> --- a/app/test/test_service_cores.c > >> +++ b/app/test/test_service_cores.c > >> @@ -445,6 +445,7 @@ static int > >> service_remote_launch_func(void *arg) > >> { > >> RTE_SET_USED(arg); > >> + rte_delay_ms(100); > >> service_remote_launch_flag =3D 1; > >> return 0; > >> } > > > > Diff below seems to fix the problem here; Aaron would you test the belo= w > fix in your setup for a while too? > > I have a loop running here attempting to reproduce - but before 100% > failures and so far 100% passes with the added wait_lcore() call. > > > > > > diff --git a/app/test/test_service_cores.c b/app/test/test_service_core= s.c > > index 9fe38f5e0..62ffedb19 100644 > > --- a/app/test/test_service_cores.c > > +++ b/app/test/test_service_cores.c > > @@ -445,6 +445,7 @@ static int > > service_remote_launch_func(void *arg) > > { > > RTE_SET_USED(arg); > > + rte_delay_ms(100); > > service_remote_launch_flag =3D 1; > > return 0; > > } > > @@ -483,6 +484,7 @@ service_lcore_en_dis_able(void) > > int ret =3D rte_eal_remote_launch(service_remote_launch_func, N= ULL, > > slcore_id); > > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch > failed."); > > + rte_eal_wait_lcore(slcore_id); > > rte_eal_mp_wait_lcore(); >=20 > Ahh, I see. Actually, this brings up a question - is the intent for > mp_wait_lcore to cycle through the service cores as well? Because IIUC, > the issue will be the lcore will be set to ROLE_RTE normally, but > service cores will do: ROLE_SERVICE and then the wait cannot work. >=20 > If the idea is that mp_wait_lcore should work (and looking at the test, > it seems like it is the intent?) then it will need to cycle through > service cores, too. If the intent is that it shouldn't, then we should > remove those calls from the test application to prevent developer from > misunderstanding. >=20 > Either way, the documentation for `rte_service_lcore_start` is a bit too > ambiguous and needs to reflect whether the mp_wait_lcore should work. I > think either it should (which means updating rte_get_next_lcore to > include ROLE_SERVICE), or none of the lcore functions should work, and > we should have an rte_service...() equivalent that should be used. Service cores are meant to be transparent to the application. The test application testing this particular usage is the corner-case. The rte_eal_mp_wait_lcore() is correct to NOT wait for service-cores, as they are not always under application control. The observed test failure is a bug in the test code, it should use the expl= icit rte_eal_wait_lcore() call. I'll send a patch later today.