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 5F2EDA04B0; Fri, 14 Aug 2020 12:01:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 382741C0CE; Fri, 14 Aug 2020 12:01:12 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 2BDAD1C020 for ; Fri, 14 Aug 2020 12:01:10 +0200 (CEST) IronPort-SDR: +O/20Lu+6Mw/p2X7cxsIvJf3rdJg3wItoc0JxC6GiedtNWO88/msfkCCiS7ZWvwHogb/6abKK8 9pTP50wN986A== X-IronPort-AV: E=McAfee;i="6000,8403,9712"; a="155491928" X-IronPort-AV: E=Sophos;i="5.76,311,1592895600"; d="scan'208";a="155491928" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Aug 2020 03:01:09 -0700 IronPort-SDR: tldO8c8NTa6q6OaEqJfMqtOnW0rKKFTQ4QcGRar0q73myCYmGl4p89wVzePHISI1CMSR82OBCk ghkeK7h+Z97w== X-IronPort-AV: E=Sophos;i="5.76,311,1592895600"; d="scan'208";a="470540798" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.45.63]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 14 Aug 2020 03:01:06 -0700 Date: Fri, 14 Aug 2020 11:01:03 +0100 From: Bruce Richardson To: Ruifeng Wang Cc: "hemant.agrawal@nxp.com" , "jerinj@marvell.com" , "viktorin@rehivetech.com" , "dev@dpdk.org" , Honnappa Nagarahalli , Phil Yang , nd Message-ID: <20200814100103.GB1970@bricha3-MOBL.ger.corp.intel.com> References: <20200814060320.86238-1-ruifeng.wang@arm.com> <20200814081306.GA1970@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms 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 Fri, Aug 14, 2020 at 09:05:23AM +0000, Ruifeng Wang wrote: > > > -----Original Message----- > > From: Bruce Richardson > > Sent: Friday, August 14, 2020 4:13 PM > > To: Ruifeng Wang > > Cc: hemant.agrawal@nxp.com; jerinj@marvell.com; > > viktorin@rehivetech.com; dev@dpdk.org; Honnappa Nagarahalli > > ; Phil Yang ; nd > > > > Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm > > platforms > > > > On Fri, Aug 14, 2020 at 02:03:20PM +0800, Ruifeng Wang wrote: > > > Flags are used to distinguish different platform architectures. > > > These flags can be used to pick different code paths for different > > > architectures at compile time. > > > For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM, > > > RTE_ARCH_ARMv7 and RTE_ARCH_ARM64. > > > RTE_ARCH_ARM64 is used to flag 64-bit aarch64 platforms, while > > > RTE_ARCH_ARM & RTE_ARCH_ARMv7 are used to flag 32-bit platforms. > > > RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested. > > > > > > The issue is that flag name RTE_ARCH_ARM is unclear and could cause > > > confusion. No info about platform word length is included in the name. > > > To make the flag names more clear, a naming scheme is proposed. > > > > > > RTE_ARCH_ARM > > > | > > > +----RTE_ARCH_ARM32 > > > | | > > > | +----RTE_ARCH_ARMv7 > > > | | > > > | +----RTE_ARCH_ARMv8_AARCH32 > > > | > > > +----RTE_ARCH_ARM64 > > > > > > RTE_ARCH_ARM32 will be used for 32-bit Arm platforms. > > > It includes RTE_ARCH_ARMv7 and RTE_ARCH_ARMv8_AARCH32. > > > RTE_ARCH_ARMv7 is for ARMv7 platforms. > > > RTE_ARCH_ARMv8_AARCH32 is for aarch32 state on aarch64 platforms. > > > RTE_ARCH_ARM64 is for 64-bit Arm platforms. > > > RTE_ARCH_ARM will be used for all Arm platforms, including > > > RTE_ARCH_ARM32 and RTE_ARCH_ARM64. > > > > > > To fit into the new naming scheme, current usage of RTE_ARCH_ARM in > > > project code is mapped to RTE_ARCH_ARM32. > > > > > > Suggested-by: Honnappa Nagarahalli > > > Signed-off-by: Ruifeng Wang > > > Reviewed-by: Phil Yang > > > --- > > Just to note that for all architectures there is the RTE_ARCH_64 define which > > is set if the system is 64-bit. That could be used instead if you didn't want to > > have to specially define ARM32 and ARM64 macros. > > > Yes. Thanks for the note. > RTE_ARCH_ARM64 is used in architecture specific cases. For example, when a processing > path is not implemented by some of 64-bit architectures, RTE_ARCH_64 is not sufficient. > Yes, but is RTE_ARCH_ARM64 not identical to RTE_ARCH_ARM && RTE_ARCH_64?