From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 577C6A0562; Fri, 19 Mar 2021 14:44:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0B4DF40143; Fri, 19 Mar 2021 14:44:43 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 9D9724003F for ; Fri, 19 Mar 2021 14:44:40 +0100 (CET) IronPort-SDR: Bt/l0kxG0kKPUbrST8gW7CEbfbReOmHJC6sl2nTDIxkOt4tTcYA4kXtkgUXMIaX9plU7Fs+x9I TzNt52D7bdVA== X-IronPort-AV: E=McAfee;i="6000,8403,9927"; a="177024333" X-IronPort-AV: E=Sophos;i="5.81,261,1610438400"; d="scan'208";a="177024333" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2021 06:44:39 -0700 IronPort-SDR: xF2Chg0cTMkI8W3XoI42kKDsUT9a/Ew7JZaahBJw2pEZJ6Jcg0OMdGECONUddDr6sGP3QsPGTp GV4EJuZ68GNw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,261,1610438400"; d="scan'208";a="434284044" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by fmsmga004.fm.intel.com with ESMTP; 19 Mar 2021 06:44:39 -0700 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 19 Mar 2021 06:44:38 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 19 Mar 2021 06:44:38 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Fri, 19 Mar 2021 06:44:38 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.170) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Fri, 19 Mar 2021 06:43:11 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g01FOBI8B50Gu0RuZTnh0dtZ/RzjYqnHiokMSEf7k3McmGSWC3stJssRddZLYGhpMOrNs51UC20C0mhUMhyhnCM2hlZTJEqN595xYGQry+XSTJkKqyOozNCHp84sRLdcx/dwiM00Um+GluNkw23XycMyotaWE4oKPriI8dzzfIVm6tKYOA4AXSAuP/8UvOrWkqeyzQL3kcbsVUVtAjScujGNO3Mu3gXOOevs61a9Bs0JLDg2EP/J8GM7BuwIE+IKdQKeOb+rBIl9dGvc5NrXTwkduej1EDNefCD3xijOhDLMnzHaenhG85toDBme09yMufwdxVW9mgujEjnaKK6apQ== 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=7VS2sBsBUu/pO7KC60eyvu+/TrRy7afveFgXK50t6Cg=; b=EMnm7/mYiy6TFugdHGeXAmes3ugaou5xoj/yfdrCD0055wjNOAqOyb+/0dfOSDNSPnN+70TqrAR/AHnOfbQNCTUkm9DZCqjHWEb7g84EZmLKcrjkE6S3eb5coiMPLcSyvBWpDpZXS7dTZrm0LIoPrqb9nPU+gcbsqySXsumPmAV3XIe0MModtYX/40Pxmdq7gbFoXnZ1S0s4h3gIPnRbbmANhhFLtajR8IsJ1hPq3JR8dIXSiW6JxLyZKyaEt/fypGKv95BMmXPe6A26tuDl7ltYnliN5dBGKY/RYfKXxNYTILT9+XkXEK/fvTqae/LHsngFcPIv9m+gyd7m6KNc9Q== 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=7VS2sBsBUu/pO7KC60eyvu+/TrRy7afveFgXK50t6Cg=; b=oSNXVD6XUzi9eckFTrX6kPFcXuZkbz4BMZfXaZcq7Cl3KjA20aLzLQfosidMbODQz1Hf+3i9UBokI8bcyQnNXLow/E8RhaSzrTTiPf4IpS7ig7uhNNBmS75BsJjXbCkbqGoEG5Q//VDrf3+5NLEqxigM5XW8X9z1IAec0ce4FuU= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB3899.namprd11.prod.outlook.com (2603:10b6:5:19c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Fri, 19 Mar 2021 13:42:39 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::3182:6da2:8c64:f07a]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::3182:6da2:8c64:f07a%3]) with mapi id 15.20.3933.032; Fri, 19 Mar 2021 13:42:39 +0000 From: "Ananyev, Konstantin" To: Honnappa Nagarahalli , "thomas@monjalon.net" , Feifei Wang , "david.marchand@redhat.com" CC: "hemant.agrawal@nxp.com" , "Nipun.gupta@nxp.com" , "jerinj@marvell.com" , "Van Haaren, Harry" , "Richardson, Bruce" , "dmitry.kozliuk@gmail.com" , "navasile@linux.microsoft.com" , "dmitrym@microsoft.com" , "Kadam, Pallavi" , "dev@dpdk.org" , Ruifeng Wang , nd , nd Thread-Topic: [RFC 3/5] eal: lcore state FINISHED is not required Thread-Index: AQHXC1KaLvvS3jTRk0+/zbaSEFIu1qppho+AgACU8QCABfHfgIAbZRPA Date: Fri, 19 Mar 2021 13:42:39 +0000 Message-ID: References: <20210224212018.17576-1-honnappa.nagarahalli@arm.com> <36690444.8nk3bCcZ7h@thomas> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [46.7.39.127] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5150ed09-62db-4b88-305c-08d8eadcdceb x-ms-traffictypediagnostic: DM6PR11MB3899: 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:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: peMfojVzF9uYEARhY8rY+fmV0tIVqW6uP2ZJZrKtlSd93MslUMUmMbDVOlmg0q1r26AxjmAeoQMOYhyCSJIPZJP27dNY1NNGminWmbm9q/59UmTzkB+mXk7nwzrKmzTz0MkbUd8lVE3BP3Qney4cJKcdQUJ06lEA8mTeV91HBs4+5z9804zx1HutndU3/2cbkWt8mgPRffllpSPaMDuYQ+AGArl5BgVVxZRfeCEsqMAK3BDlTQTz2B9fNLbbWrKU9uINFRAxc06SCcE+z4EtbjIzbJTXZf3nz7amWwUuVbIU8EoB/+YKFGI4SW7MeHaVlP9cdwRsul7xeb9dVfy7imFI0j2ZR9botbVF6ChLYgS2tgm3scHRPBo0tXZoixSfFhXTlTBR5RMaxN70VjFLMrhEu/sisynO8FIQ35KfJY47oYn0fVtU+YA+eAt0ox6M6zdHwKS/gQh+j5h2T+7ZjfWfyc1vcsd1LPtYKVxls2gZsJBPqAcSy+gKPVffgTpWl3YnCCC2nIHyOWIU0JYb332PuxN0r8lb9ViJh2Wa8nu2OhFNpOevHl7hHys+xobNc/dAJPAFeWD3KWwY5r/lGeUk8HGLARUTUWS6/VlVaA0eRjTj8ZLWbj8aaj6smdIB8S9/cR9Kgt+HD2odxu6XC3cAhYD3ZVsAK6pDWsz+OqI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(396003)(366004)(39860400002)(76116006)(66946007)(66446008)(33656002)(26005)(8936002)(5660300002)(6506007)(66476007)(38100700001)(64756008)(110136005)(66556008)(55016002)(52536014)(9686003)(86362001)(8676002)(7696005)(54906003)(71200400001)(4326008)(478600001)(186003)(2906002)(7416002)(316002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?WUnSonLcK3KmJTzN+Wne2Un/AOIAaLFslL7ZJeepYOUOLIuMwtfVvRrxyAuu?= =?us-ascii?Q?kFZLlzP891y4tKQo45bIpgShckqbw+Ebd0K3eg71Ty6/yGH/JBLl2KK7fsuL?= =?us-ascii?Q?mmBvZr13VvdkwfNahCVhAD8UYv4ZMVEA+MNyrZTWbvhM6vsQ3MPTdo4EAg/B?= =?us-ascii?Q?g+2ksrS7s8uCqcLcs3qm+lbUCoGaGMS6kHuCcNbzshuaz+MXD6xWLByPYC0K?= =?us-ascii?Q?4ieOEnPA8AmVm4RzYdvq7yOMIxsirkU0/j4ngoFLR1P4Tu5fZKhg1gT1Nb+x?= =?us-ascii?Q?QEewqFamAaB8Sdw++kjdMuznaG/Hyss52LfJkCIPF6BLlTIwTf67Yhclyc8X?= =?us-ascii?Q?mHE/Sjl00hwFCLDF+KG2c+9RDtcwtqEX2madtvn9gubrtqmWSFrUDwO/ZYV+?= =?us-ascii?Q?HJVt3Ry0swwPboOX8Sdv63rU6I21MeOfzexl9CyvcSHVVeG2/WIg7SpvhaNa?= =?us-ascii?Q?8xpH5gBeWRJ8HLKL6makj7LqXgLylYMSMcCh6CJIoQ7G7BoTqRkmgqfusBr9?= =?us-ascii?Q?yAbsnCdpQgrPkdUblCKKOSEqJt95qVzcmjTkW7/YxX0PgO9ZSr5V4/4Aes+h?= =?us-ascii?Q?SQDAD37gQWjcknqYPDG97b1Xx9khgZtLPmJ1CQa29vEXKF/ouuhaaXIuBT2F?= =?us-ascii?Q?mG9m000FdoR0VruH2KzlY85T79hLZO9lBHvJQPzliI/PucHROFctPktcwLXn?= =?us-ascii?Q?VI6fuJpwhJriAOPg0uGBv2KMW17hi9w4HPeeCt+WK/j8+kS76GQZ/WFV40hK?= =?us-ascii?Q?GHrrQwIwaN27EeXT58qJVZ6sS3XmrRgrEvoYytNQFrhedgcUUUjYTj/sPy/v?= =?us-ascii?Q?reebPxzlC/FhHRtwbV6dfYJYS1SQIYhApXohv0SsJYkY9pTUjH4OqnDS+lRL?= =?us-ascii?Q?9UW/VTijuoOTVYJifVOXotsBNeZN0f6csFvcPLr7V2577vHJ3T4MR0WA848a?= =?us-ascii?Q?qnz+zvI3I1FcFBwlKxMHqLOxjUIgZelpnDRB8+5PGvzqGQr7hh4c7MWILp+q?= =?us-ascii?Q?XVYCP72DSKu5xzxbQwlG+PKk+8QK6vxNZen1k0bIqtoIgssUUBtMqsrFX+e9?= =?us-ascii?Q?tj+Qp5qPGUCkytZcc0v5Hg4UrMfnEMgOEo31p+ncRh/6wB7tjtBJwDuGgbPt?= =?us-ascii?Q?4YCXorJega9ho+fqt/Zv1fuIJbo2R12e/yYeWw005mMS+NobeetWNdq8hGxN?= =?us-ascii?Q?0L5JUr5a2M3SJmuxGO8S3EmyE7rTZZuWt8HvubIn03Vij27wk5I5CJnClfHK?= =?us-ascii?Q?rAP1ml+TvAdZo0MUfn78IXj/Egl7nZgvDgaDcAEeeFNVsa/ZBnPUZWACNzyh?= =?us-ascii?Q?zfc=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5150ed09-62db-4b88-305c-08d8eadcdceb X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 13:42:39.1611 (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: jDGEFF3S2oMCyqjEQgztjrKo2eV4yhDswGTzOy26FAC5bJ5/MkpVeqdgHHZQQuI9zLRUYsftV2dHbrln1n9vUuS5f2DbtCE1WgGjsWGvAnQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3899 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [RFC 3/5] eal: lcore state FINISHED is not required X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Hi everyone, > >=20 > > > > > > > > Subject: [RFC 3/5] eal: lcore state FINISHED is not required > > > > > > > > > > FINISHED state seems to be used to indicate that the worker's > > > > > update of the 'state' is not visible to other threads. There seem= s > > > > > to be no requirement to have such a state. > > > > > > > > I am not sure "FINISHED" is necessary to be removed, and I propose > > > > some of my profiles for discussion. > > > > There are three states for lcore now: > > > > "WAIT": indicate lcore can start working > > > > "RUNNING": indicate lcore is working > > > > "FINISHED": indicate lcore has finished its working and wait to be > > > > reset > > > If you look at the definitions of "WAIT" and "FINISHED" states, they = look > > similar, except for "wait to be reset" in "FINISHED" state . The code r= eally does > > not do anything to reset the lcore. It just changes the state to "WAIT"= . I agree that 3 states here seems excessive. Just 2 (RUNNING/IDLE) seems enough. Though we can't just remove FINISHED here - it will be an Abi breakage. Might be deprecate FINISHED now and remove in 21.11. Also need to decide what rte_eal_wait_lcore() should return in that case? Always zero, or always status of last function called? > > > > > > > > > > > From the description above, we can find "FINISHED" is different fro= m > > > > "WAIT", it can shows that lcore has done the work and finished it. > > > > Thus, if we remove "FINISHED", maybe we will not know whether the > > > > lcore finishes its work or just doesn't start, because this two sta= te has the > > same tag "WAIT". > > > Looking at "eal_thread_loop", the worker thread sets the state to "RU= NNING" > > before sending the ack back to main core. After that it is guaranteed t= hat the > > worker will run the assigned function. Only case where it will not run = the > > assigned function is when the 'write' syscall fails, in which case it r= esults in a > > panic. > > > > Quick note: it should not panic. > > We must find a way to return an error > > without crashing the whole application. > The syscalls are being used to communicate the status back to the main th= read. If they fail, it is not possible to communicate the status. > May be it is better to panic. > We could change the implementation using shared variables, but it would r= equire polling the memory. May be the syscalls are being used to > avoid polling. However, this polling would happen during init time (or si= milar) for a short duration. AFAIK we use read and write not for status communication, but sort of sleep= /ack point. Though I agree if we can't do read/write from the system pipe then somethin= g is totally wrong, and probably there is no much point to continue.=20 =20 > > > > > > > > Furthermore, consider such a scenario: > > > > Core 1 need to monitor Core 2 state, if Core 2 finishes one task, > > > > Core 1 can start its working. > > > > However, if there is only one tag "WAIT", Core 1 maybe start its > > > > work at the wrong time, when Core 2 still does not start its task a= t state > > "WAIT". > > > > This is just my guess, and at present, there is no similar > > > > application scenario in dpdk. > > > To be able to do this effectively, core 1 needs to observe the state = change > > from WAIT->RUNNING->FINISHED. This requires that core 1 should be calli= ng > > rte_eal_remote_launch and rte_eal_wait_lcore functions. It is not possi= ble to > > observe this state transition from a 3rd core (for ex: a worker might g= o from > > RUNNING->FINISHED->WAIT->RUNNING which a 3rd core might not be able to > > observe). > > > > > > > > > > > On the other hand, if we decide to remove "FINISHED", please > > > > consider the following files: > > > > 1. lib/librte_eal/linux/eal_thread.c: line 31 > > > > lib/librte_eal/windows/eal_thread.c: line 22 > > > > lib/librte_eal/freebsd/eal_thread.c: line 31 > > > I have looked at these lines, they do not capture "why" FINISHED stat= e is > > required. > > > > > > 2. > > > > lib/librte_eal/include/rte_launch.h: line 24, 44, 121, 123, 131 3. > > > > examples/l2fwd- > > > > keepalive/main.c: line 510 > > > > rte_eal_wait_lcore(id_core) can be removed. Because the core state > > > > has been checked as "WAIT", this is a redundant operation > > > >