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 970BC45561; Wed, 3 Jul 2024 15:33:13 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 83304410FB; Wed, 3 Jul 2024 15:33:13 +0200 (CEST) Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com [103.168.172.151]) by mails.dpdk.org (Postfix) with ESMTP id 2317D402AD for ; Wed, 3 Jul 2024 15:33:12 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 934CC138019C; Wed, 3 Jul 2024 09:33:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 03 Jul 2024 09:33:11 -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=1720013591; x=1720099991; bh=8Q/QgBR7mOo9bUiBMGTpDENJngQNmrdAOmbIQ8uv7vE=; b= YmXtSKE/M/HVdc3aUtQ0z/IUQcDj6XjBdsS6vzBn/bWtEdCYudz5fjm53EqIE4tP SGGkeoTGNa4M4n9Kqjtx+GZWM9DuzwMD7AsBKsgOg8idPy29BmkOroktg2VUTVou dETg4RnDTJ3OmnJhBQTGN4EzNCIykEBX93Kkiu29E4vzG6SW4Km8TZXeX5ga4qJI aQCX4Lp802UMl3LtDLkITpKgtdcx6OE+m13ua9fXrss/Nc79pYQG+d29H0R0420l 2kVs6XpjHQFmW/sEcZbVJ+JSK0dylgDpJ+Gt+9O54WT+3JwWh+Utlsrv0s8izaiy lWa41QPUHfcGKm1k8JAzjg== 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=1720013591; x= 1720099991; bh=8Q/QgBR7mOo9bUiBMGTpDENJngQNmrdAOmbIQ8uv7vE=; b=c 2EKHhfMKaj+nx2nmUWlaHQ9spkshUpFdR/mBLulcNb+7yRgLjoeD1ODzawduKwXK Qff3Ry6VUbQQPTrVAaOZ4EcoAMDMWI0fgD1VKcd+EQykmsmgLxtC117GUiabMQN8 TMJB5dwWpUCFjbCdTKBzDXx5oPNA16R/HVOkZx8Qkv3Gqf4wJZzB2CQo42WaTUyp nsiQosGbMvGRPo33HARqek2kPjdFzJ1I41Q/kmqtktBAA4/ONJwUC4ZJv/aYUHZ/ iFhMWCbLvns2Dda4X/MYiY6EK/wlQ6TcMfXHIrHAEQ/3tLz7CVpsgixG+1AJMY1s t3/wkA4icT7Mm5QEbSuvA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudejgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeduveehieevuddutdevfffgtdegkeeuveejffejgedtgeegkefg vdeugfefkeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Jul 2024 09:33:09 -0400 (EDT) From: Thomas Monjalon To: Wathsala Wathawana Vithanage Cc: Tyler Retzlaff , Ruifeng Wang , "dev@dpdk.org" , nd , Dhruv Tripathi , Honnappa Nagarahalli , Jack Bond-Preston , Nick Connolly , Vinod Krishna , "david.marchand@redhat.com" Subject: Re: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics Date: Wed, 03 Jul 2024 15:33:07 +0200 Message-ID: <6302927.2eNUzBXWct@thomas> In-Reply-To: References: <20240604044401.3577707-2-wathsala.vithanage@arm.com> <859956985.pAmPZ1aGmH@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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 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.