[dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms

Ruifeng Wang Ruifeng.Wang at arm.com
Wed Aug 19 10:01:14 CEST 2020


> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit at intel.com>
> Sent: Tuesday, August 18, 2020 10:36 PM
> To: Ruifeng Wang <Ruifeng.Wang at arm.com>; hemant.agrawal at nxp.com;
> jerinj at marvell.com; viktorin at rehivetech.com
> Cc: dev at dpdk.org; Honnappa Nagarahalli
> <Honnappa.Nagarahalli at arm.com>; Phil Yang <Phil.Yang at arm.com>; nd
> <nd at arm.com>
> Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm
> platforms
> 
> On 8/14/2020 7:03 AM, 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 <honnappa.nagarahalli at arm.com>
> > Signed-off-by: Ruifeng Wang <ruifeng.wang at arm.com>
> > Reviewed-by: Phil Yang <phil.yang at arm.com>
> > ---
> 
> <...>
> 
> > @@ -6,7 +6,7 @@
> >  CONFIG_RTE_MACHINE="armv7a"
> >
> >  CONFIG_RTE_ARCH="arm"
> > -CONFIG_RTE_ARCH_ARM=y
> > +CONFIG_RTE_ARCH_ARM32=y
> >  CONFIG_RTE_ARCH_ARMv7=y
> >  CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
> 
> According commit log message I thought 'RTE_ARCH_ARM' will be always set,
> isn't it the case?
> 
> Is below wrong:
> aarch64  -> ARM | ARM64 | ARCH_64
> armv7a   -> ARM | ARM32 | ARMv7
> aarch32  -> ARM | ARM32 | ARMv8_AARCH32
> 
Yes, it is.
This is correct.

> If so some of the 'defined(RTE_ARCH_ARM32) ||
> defined(RTE_ARCH_ARM64)' checks can be simplified as
> 'defined(RTE_ARCH_ARM)'
> 
Will do the change when converting this RFC to a patch.

> 
> Also currently missing 'ARCH_64' flag implies the 32bit support, for all
> architectures, what about having a common 'ARCH_32' flag and use for all
> arch, instead of 'ARM32'? So something like below:
> aarch64  -> ARM | ARM64 | ARCH_64
> armv7a   -> ARM | ARMv7 | ARCH_32
> aarch32  -> ARM | ARMv8_AARCH32 | ARCH_32
> 
Having a common 'ARCH_32' flag for all arch is good.

Then for Arm we will have:
RTE_ARCH_ARM
    |
    +----RTE_ARCH_32
    |        |
    |        +----RTE_ARCH_ARMv7
    |        |
    |        +----RTE_ARCH_ARMv8_AARCH32
    |
    +----RTE_ARCH_64
             |
             +----RTE_ARCH_ARM64

For x86 we will have:
RTE_ARCH_X86
    |
    +----RTE_ARCH_32
    |        |
    |        +----RTE_ARCH_I686
    |        |
    |        +----RTE_ARCH_X86_X32
    |
    +----RTE_ARCH_64
             |
             +----RTE_ARCH_X86_64

For PowerPC we will have: RTE_ARCH_PPC_64

> 
> 
> 
> Just to record matching flags for other archs are:
> 
> x86_64  -> X86 | X86_64 | ARCH_64
> i686    -> X86 | I686
> x86_32  -> X86 | X86_32
> 
> ppc_64  -> PPC_64 | ARCH_64



More information about the dev mailing list