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 17D8A4558A; Thu, 4 Jul 2024 16:14:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08B144042F; Thu, 4 Jul 2024 16:14:49 +0200 (CEST) Received: from fhigh3-smtp.messagingengine.com (fhigh3-smtp.messagingengine.com [103.168.172.154]) by mails.dpdk.org (Postfix) with ESMTP id A46BB4025C for ; Thu, 4 Jul 2024 16:14:47 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 3CA0D1140279; Thu, 4 Jul 2024 10:14:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 04 Jul 2024 10:14:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1720102487; x=1720188887; bh=Hr4pD3umKlCZPXKVojKASBWl1COqOXX/I4VKH7Q6Te8=; b= RFGbVGzYs7UKd7+iPnDd8PDJy4xwGpYjPok3GJNMy9Wz7madm69G2d2PNFqM1zlY W5ZKHZ3FinPd90PZoJ3DrWJkDZ5aOMgetW7187WdFmUkwNwn1sCJSndZre7pjZOz XkK62Fh3iIJdkUB+B3S3J77cMoYoUoMeQCq7hKA/3pNj35LMGHFINXmabJPPVfe0 Sv6MIPjZJ+BfH+BH+JUt8yEy1dm6qEdoU8ZqIJqnHigMQIMfARug7aVDdZw7J7zx GmbrbfZ35FqaBEeMgc9u5LZa6CE6Q/5tWTxagcwQ7Ydpj95TDyR98uExE/a+/+/p jHwv1RGu4MVrevQjwQ7EmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720102487; x= 1720188887; bh=Hr4pD3umKlCZPXKVojKASBWl1COqOXX/I4VKH7Q6Te8=; b=D 0tHMutfBt52xq35dpnSP0pmgWdPhZ3j9CsNGdIHhRslxM/C2L1YI1jgtGDW/HYUe DaXokbfyhuegDJRqHbXweHAxWJZ5q9eiOQeI5GtD4lKAsyZNBiNSP1OU7yM3Cxfv M+FuPVNNVQfou25e7afGutqMFDVhb+0KPe7jhySE9834l/6yX+pxLvXDFqTjoIl9 ZmYU2ZF2sNDcrBNmetKVmHCeopESqdgTZvDoJHypzxKosKzHkaRPtWGosW9bumMt F3Pg3o8UPMs2BL/dBfwl6NXnZRA19c1xa7RBBWwPhcRpsYT3c09W39CoW9/MRJr0 8xkYGFSxqmG11ySs9RjAA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudelgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedviedu vdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Jul 2024 10:14:44 -0400 (EDT) From: Thomas Monjalon To: Pavan Nikhilesh Bhagavatula Cc: Wathsala Wathawana Vithanage , Tyler Retzlaff , Ruifeng Wang , "dev@dpdk.org" , nd , Dhruv Tripathi , Honnappa Nagarahalli , Jack Bond-Preston , Nick Connolly , Vinod Krishna , "david.marchand@redhat.com" , nd Subject: Re: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics Date: Thu, 04 Jul 2024 16:14:42 +0200 Message-ID: <4208140.dumfJixkPq@thomas> In-Reply-To: References: <20240604044401.3577707-2-wathsala.vithanage@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 04/07/2024 12:55, Pavan Nikhilesh Bhagavatula: > > > 03/07/2024 15:27, Wathsala Wathawana Vithanage: > > > > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED #ifdef block. > > > > > > This patch fixes this issue by moving __RTE_ARM_WFE out of > > > > > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED block. > > > > > > > > > > > > Perhaps we should change RTE_ARM_USE_WFE to something like > > > > > > RTE_ARM_USE_WFE_IN_WAIT_UNTIL_EQUAL ? > > > > > > > > > > Yes perhaps. > > > > RTE_ARM_USE_WFE is already used in drivers/event/cnxk/cn10k_worker.h > > > > therefore RTE_ARM_USE_WFE_IN_WAIT_UNTIL_EQUAL is not suitable. > > > > I wouldn't mind keeping RTE_ARM_USE_WFE because "USE_WFE" sounds > > > like > > > > an instruction to use WFE rather than an indication of availability= of the > > WFE > > > instruction. > > > > > > The problem is that the definition of this flag is not clear. > > > What is it doing? > > > If it's really disabling WFE, keep the #ifdef to not use it. > > > > > > For now, it is a nack of this patch for all reasons described before. > > > > >=20 > > Only other place where this flag is used is drivers/event/cnxk/cn10k_wo= rker.h > >=20 > > b8dbcbe8a57 (Pavan Nikhilesh 2024-02-27 13:41:53 +0530 284) #if > > defined(RTE_ARM_USE_WFE) > >=20 > > Let=E2=80=99s ask Pavan why this flag is used in cn10k driver. > >=20 > > From our perspective, WFE is available on all the supported arm platfor= ms in > > DPDK. > > Therefore, RTE_ARM_USE_WFE should be treated as a flag to choose between > > WFE > > and non-WFE code paths due to performance reasons rather than as a flag > > that indicates > > the availability of the instruction on the target CPU. > >=20 >=20 > We are using this flag to allow application to choose between WFE and non= =2DWFE code path. > The non-WFE path performs slightly better. What's the benefit of the WFE path then?