Re: [dpdk-dev] [EXT] Default cacheline size for ARM
On Thu, 2019-01-31 at 18:09 +, Honnappa Nagarahalli wrote: > + Phil and Hemant > > > > > > > > > Yes, we need to be inline with any other package. My > > > > > > understanding is that the image will be same for v8,v9,v10 > > > > > > (any > > > > > > input from distro engineers will help here). So, my > > > > > > question is, > > > > > > should the config file/name used by distros contain > > > > > > anything > > > > > > specific to armv8? > > > > > Jerin, after following [1], I am not unable to understand > > > > > when the > > > > > file config/arm/arm64_armv8_linuxapp_gcc gets used. Is this > > > > > file > > > > > required? > > > > > > > > If I understand it correctly, only for cross compiling on x86. > > > > distro folks build the generic image on arm64 with > > > > -Dmachine=default > > > > for arm64. > > > I thought for cross compilation we have target specific config > > > files > > > in config/arm. For ex: arm64_dpaa2_linuxapp_gcc, > > > arm64_thunderx_linuxapp_gcc > > > > Yes. config/arm/arm64_armv8_linuxapp_gcc will be used for cross > > compile > > arm64 image, equivalent to config/defconfig_arm64-armv8a-linuxapp- > > gcc > > in cross compiling domain for meson. > > > Following is my understanding: > 1) Distro folks build the generic image on arm64 with > -Dmachine=default for arm64 ( > http://mails.dpdk.org/archives/dev/2019-January/123272.html) > 2) Target specific builds and cross compilation is done using target > specific configuration files (for ex: > config/arm/arm64_dpaa2_linuxapp_gcc etc) > > Are you saying, we need a cross compile mechanism to generate generic > arm64 image (that would work across all Arm platforms)? > Do you have any use cases in mind for this? # I was thinking, Not everyone has access to arm64 machine so having one generic cross compile target can function as build sanity check for arm64 on x86 machines. # The _buildroot_ kind of tiny embedded rootfs can not have gcc on target, so this config will be useful for such build enablement as default option. > > > > > > 1. > > > > > http://mails.dpdk.org/archives/dev/2019-January/123272.html
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
+ Phil and Hemant > > > > > Yes, we need to be inline with any other package. My > > > > > understanding is that the image will be same for v8,v9,v10 (any > > > > > input from distro engineers will help here). So, my question is, > > > > > should the config file/name used by distros contain anything > > > > > specific to armv8? > > > > Jerin, after following [1], I am not unable to understand when the > > > > file config/arm/arm64_armv8_linuxapp_gcc gets used. Is this file > > > > required? > > > > > > If I understand it correctly, only for cross compiling on x86. > > > distro folks build the generic image on arm64 with -Dmachine=default > > > for arm64. > > I thought for cross compilation we have target specific config files > > in config/arm. For ex: arm64_dpaa2_linuxapp_gcc, > > arm64_thunderx_linuxapp_gcc > > Yes. config/arm/arm64_armv8_linuxapp_gcc will be used for cross compile > arm64 image, equivalent to config/defconfig_arm64-armv8a-linuxapp-gcc > in cross compiling domain for meson. > Following is my understanding: 1) Distro folks build the generic image on arm64 with -Dmachine=default for arm64 (http://mails.dpdk.org/archives/dev/2019-January/123272.html) 2) Target specific builds and cross compilation is done using target specific configuration files (for ex: config/arm/arm64_dpaa2_linuxapp_gcc etc) Are you saying, we need a cross compile mechanism to generate generic arm64 image (that would work across all Arm platforms)? Do you have any use cases in mind for this? > > > > > > > > > 1. http://mails.dpdk.org/archives/dev/2019-January/123272.html
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
On Wed, 2019-01-23 at 16:28 +, Honnappa Nagarahalli wrote: > > On Fri, 2019-01-18 at 05:50 +, Honnappa Nagarahalli wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM > > > > > > > > > > CPUs is > > > > > > > > > > set to be 128B by default. Mellanox's BlueField is > > > > > > > > > > an > > > > > > > > > > ARM CPU having > > > > > > > > > > Cortex-A72 > > > > > > > > > > and its CL size is 64B. > > > > > > > > Just wondering how many devices are out there with 128B > > > > > > > > cache line? I also have not heard about any future > > > > > > > > devices > > > > > > > > with 128B cache line. If the majority is 64B, why not > > > > > > > > keep > > > > > > > > 64B as the default? > > > > > > > > > > > > > > The problem is, In the armv8 spec the cache line size is > > > > > > > IMPLEMENTATION DEFINED. Marvell's embedded processors has > > 128B > > > > CL > > > > > > > and Server processors has 64B CL. > > > > > > > > > > > > > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be > > > > > > > used > > > > > > > by distro folks then that configuration should support > > > > > > > all the > > > > > > > devices with > > > > > > > armv8.1 spec. For instance, marvells new chips are > > > > > > > armv8.2 but > > > > > > > we can not make that as default. > > > > > > What will happen in the future when we will have v9, v10 > > > > > > etc? I > > > > > > think the distro(generic/binary portable) config should get > > > > > > rid > > > > > > of v8. > > > > > > > > > > Will it be too much overhead if the image is same for v8, v9 > > > > > and > > > > > v10. > > > > > I think, we can inline with what distro folks are doing for > > > > > other > > > > > packages, I think, DPDK package does not need any exception. > > > > Yes, we need to be inline with any other package. My > > > > understanding > > > > is that the image will be same for v8,v9,v10 (any input from > > > > distro > > > > engineers will help here). So, my question is, should the > > > > config > > > > file/name used by distros contain anything specific to armv8? > > > Jerin, after following [1], I am not unable to understand when > > > the > > > file config/arm/arm64_armv8_linuxapp_gcc gets used. Is this file > > > required? > > > > If I understand it correctly, only for cross compiling on x86. > > distro folks build the generic image on arm64 with > > -Dmachine=default for > > arm64. > I thought for cross compilation we have target specific config files > in config/arm. For ex: arm64_dpaa2_linuxapp_gcc, > arm64_thunderx_linuxapp_gcc Yes. config/arm/arm64_armv8_linuxapp_gcc will be used for cross compile arm64 image, equivalent to config/defconfig_arm64-armv8a-linuxapp-gcc in cross compiling domain for meson. > > > > > > 1. http://mails.dpdk.org/archives/dev/2019-January/123272.html
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
> On Fri, 2019-01-18 at 05:50 +, Honnappa Nagarahalli wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is > > > > > > > > > set to be 128B by default. Mellanox's BlueField is an > > > > > > > > > ARM CPU having > > > > > > > > > Cortex-A72 > > > > > > > > > and its CL size is 64B. > > > > > > > Just wondering how many devices are out there with 128B > > > > > > > cache line? I also have not heard about any future devices > > > > > > > with 128B cache line. If the majority is 64B, why not keep > > > > > > > 64B as the default? > > > > > > > > > > > > The problem is, In the armv8 spec the cache line size is > > > > > > IMPLEMENTATION DEFINED. Marvell's embedded processors has > 128B > > > CL > > > > > > and Server processors has 64B CL. > > > > > > > > > > > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used > > > > > > by distro folks then that configuration should support all the > > > > > > devices with > > > > > > armv8.1 spec. For instance, marvells new chips are armv8.2 but > > > > > > we can not make that as default. > > > > > What will happen in the future when we will have v9, v10 etc? I > > > > > think the distro(generic/binary portable) config should get rid > > > > > of v8. > > > > > > > > Will it be too much overhead if the image is same for v8, v9 and > > > > v10. > > > > I think, we can inline with what distro folks are doing for other > > > > packages, I think, DPDK package does not need any exception. > > > Yes, we need to be inline with any other package. My understanding > > > is that the image will be same for v8,v9,v10 (any input from distro > > > engineers will help here). So, my question is, should the config > > > file/name used by distros contain anything specific to armv8? > > Jerin, after following [1], I am not unable to understand when the > > file config/arm/arm64_armv8_linuxapp_gcc gets used. Is this file > > required? > > If I understand it correctly, only for cross compiling on x86. > distro folks build the generic image on arm64 with -Dmachine=default for > arm64. I thought for cross compilation we have target specific config files in config/arm. For ex: arm64_dpaa2_linuxapp_gcc, arm64_thunderx_linuxapp_gcc > > > > > > 1. http://mails.dpdk.org/archives/dev/2019-January/123272.html >
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
On Fri, 2019-01-18 at 05:50 +, Honnappa Nagarahalli wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs > > > > > > > > is set > > > > > > > > to be 128B by default. Mellanox's BlueField is an ARM > > > > > > > > CPU > > > > > > > > having > > > > > > > > Cortex-A72 > > > > > > > > and its CL size is 64B. > > > > > > Just wondering how many devices are out there with 128B > > > > > > cache > > > > > > line? I also have not heard about any future devices with > > > > > > 128B > > > > > > cache line. If the majority is 64B, why not keep 64B as the > > > > > > default? > > > > > > > > > > The problem is, In the armv8 spec the cache line size is > > > > > IMPLEMENTATION DEFINED. Marvell's embedded processors has > > > > > 128B > > CL > > > > > and Server processors has 64B CL. > > > > > > > > > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used > > > > > by > > > > > distro folks then that configuration should support all the > > > > > devices with > > > > > armv8.1 spec. For instance, marvells new chips are armv8.2 > > > > > but we > > > > > can not make that as default. > > > > What will happen in the future when we will have v9, v10 etc? I > > > > think the distro(generic/binary portable) config should get rid > > > > of v8. > > > > > > Will it be too much overhead if the image is same for v8, v9 and > > > v10. > > > I think, we can inline with what distro folks are doing for other > > > packages, I think, DPDK package does not need any exception. > > Yes, we need to be inline with any other package. My understanding > > is that > > the image will be same for v8,v9,v10 (any input from distro > > engineers will > > help here). So, my question is, should the config file/name used by > > distros > > contain anything specific to armv8? > Jerin, after following [1], I am not unable to understand when the > file config/arm/arm64_armv8_linuxapp_gcc gets used. Is this file > required? If I understand it correctly, only for cross compiling on x86. distro folks build the generic image on arm64 with -Dmachine=default for arm64. > > 1. http://mails.dpdk.org/archives/dev/2019-January/123272.html
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
> > > > > > > Hi, > > > > > > > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set > > > > > > > to be 128B by default. Mellanox's BlueField is an ARM CPU > > > > > > > having > > > > > > > Cortex-A72 > > > > > > > and its CL size is 64B. > > > > > Just wondering how many devices are out there with 128B cache > > > > > line? I also have not heard about any future devices with 128B > > > > > cache line. If the majority is 64B, why not keep 64B as the > > > > > default? > > > > > > > > The problem is, In the armv8 spec the cache line size is > > > > IMPLEMENTATION DEFINED. Marvell's embedded processors has 128B > CL > > > > and Server processors has 64B CL. > > > > > > > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used by > > > > distro folks then that configuration should support all the > > > > devices with > > > > armv8.1 spec. For instance, marvells new chips are armv8.2 but we > > > > can not make that as default. > > > What will happen in the future when we will have v9, v10 etc? I > > > think the distro(generic/binary portable) config should get rid of v8. > > > > Will it be too much overhead if the image is same for v8, v9 and v10. > > I think, we can inline with what distro folks are doing for other > > packages, I think, DPDK package does not need any exception. > Yes, we need to be inline with any other package. My understanding is that > the image will be same for v8,v9,v10 (any input from distro engineers will > help here). So, my question is, should the config file/name used by distros > contain anything specific to armv8? Jerin, after following [1], I am not unable to understand when the file config/arm/arm64_armv8_linuxapp_gcc gets used. Is this file required? 1. http://mails.dpdk.org/archives/dev/2019-January/123272.html
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
> > > > > > Hi, > > > > > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set > > > > > > to be 128B by default. Mellanox's BlueField is an ARM CPU > > > > > > having > > > > > > Cortex-A72 > > > > > > and its CL size is 64B. > > > > Just wondering how many devices are out there with 128B cache > > > > line? I also have not heard about any future devices with 128B > > > > cache line. If the majority is 64B, why not keep 64B as the > > > > default? > > > > > > The problem is, In the armv8 spec the cache line size is > > > IMPLEMENTATION DEFINED. Marvell's embedded processors has 128B CL > > > and Server processors has 64B CL. > > > > > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used by > > > distro folks then that configuration should support all the devices > > > with > > > armv8.1 spec. For instance, marvells new chips are armv8.2 but we > > > can not make that as default. > > What will happen in the future when we will have v9, v10 etc? I think > > the distro(generic/binary portable) config should get rid of v8. > > Will it be too much overhead if the image is same for v8, v9 and v10. > I think, we can inline with what distro folks are doing for other packages, I > think, DPDK package does not need any exception. Yes, we need to be inline with any other package. My understanding is that the image will be same for v8,v9,v10 (any input from distro engineers will help here). So, my question is, should the config file/name used by distros contain anything specific to armv8?
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
On Mon, 2019-01-14 at 07:47 +, Honnappa Nagarahalli wrote: > > On Sat, 2019-01-05 at 22:47 +, Honnappa Nagarahalli wrote: > > > > On Fri, 2019-01-04 at 19:59 +, Yongseok Koh wrote: > > > > > --- > > > > > > > > > > > > > > > --- > > > > > Hi, > > > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set > > > > > to be > > > > > 128B by default. Mellanox's BlueField is an ARM CPU having > > > > > Cortex-A72 > > > > > and its CL size is 64B. > > > Just wondering how many devices are out there with 128B cache > > > line? I > > > also have not heard about any future devices with 128B cache > > > line. If > > > the majority is 64B, why not keep 64B as the default? > > > > The problem is, In the armv8 spec the cache line size is > > IMPLEMENTATION > > DEFINED. Marvell's embedded processors has 128B CL and Server > > processors > > has 64B CL. > > > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used by > > distro > > folks then that configuration should support all the devices with > > armv8.1 spec. For instance, marvells new chips are armv8.2 but we > > can not > > make that as default. > What will happen in the future when we will have v9, v10 etc? I think > the distro(generic/binary portable) config should get rid of v8. Will it be too much overhead if the image is same for v8, v9 and v10. I think, we can inline with what distro folks are doing for other packages, I think, DPDK package does not need any exception.
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
> On Sat, 2019-01-05 at 22:47 +, Honnappa Nagarahalli wrote: > > > On Fri, 2019-01-04 at 19:59 +, Yongseok Koh wrote: > > > > --- > > > > > > > > --- > > > > Hi, > > > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set to be > > > > 128B by default. Mellanox's BlueField is an ARM CPU having > > > > Cortex-A72 > > > > and its CL size is 64B. > > Just wondering how many devices are out there with 128B cache line? I > > also have not heard about any future devices with 128B cache line. If > > the majority is 64B, why not keep 64B as the default? > > The problem is, In the armv8 spec the cache line size is IMPLEMENTATION > DEFINED. Marvell's embedded processors has 128B CL and Server processors > has 64B CL. > > Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used by distro > folks then that configuration should support all the devices with > armv8.1 spec. For instance, marvells new chips are armv8.2 but we can not > make that as default. What will happen in the future when we will have v9, v10 etc? I think the distro(generic/binary portable) config should get rid of v8. > > Target specific configuration can be used for optimized target specific > configuration. > > Or any other ideas for distro config. > > > > > > > I can add config/defconfig_arm64-bluefield-linuxapp-gcc for legacy > > > > build anyway. > > > > > > > > > > Makes sense. > > > > > > > For the meson build, I know it parses the Main ID register to > > > > figure > > > > out Implementor ID and Part Number. However, Mellanox doesn't > > > > program > > > > our own ID yet but we set the Part Number as 0xd08 (A72). > > > > According to my folks, ARM's A53, A57, A72, and A73 designs all > > > > have > > > > 64B CL. If that's true, can I push a patch to make the change? > > > > > > Yes. Broadcom Stingray has the same situation i.e Use > > > flags_generic, > > > machine_args_generic > > > > > This will solve only the native compilation issue. It will not > > address distro compilation (may be this is not your goal?). > > See above. > > > > > > > Please comment. > > > > > > > > > > > > Thanks, > > > > Yongseok > > > >
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
On Sat, 2019-01-05 at 22:47 +, Honnappa Nagarahalli wrote: > > On Fri, 2019-01-04 at 19:59 +, Yongseok Koh wrote: > > > --- > > > > > > --- > > > Hi, > > > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set to > > > be > > > 128B by default. Mellanox's BlueField is an ARM CPU having > > > Cortex-A72 > > > and its CL size is 64B. > Just wondering how many devices are out there with 128B cache line? I > also have not heard about any future devices with 128B cache line. If > the majority is 64B, why not keep 64B as the default? The problem is, In the armv8 spec the cache line size is IMPLEMENTATION DEFINED. Marvell's embedded processors has 128B CL and Server processors has 64B CL. Assuming the defconfig_arm64-armv8a-linuxapp-gcc will be used by distro folks then that configuration should support all the devices with armv8.1 spec. For instance, marvells new chips are armv8.2 but we can not make that as default. Target specific configuration can be used for optimized target specific configuration. Or any other ideas for distro config. > > > > I can add config/defconfig_arm64-bluefield-linuxapp-gcc for > > > legacy > > > build anyway. > > > > > > > Makes sense. > > > > > For the meson build, I know it parses the Main ID register to > > > figure > > > out Implementor ID and Part Number. However, Mellanox doesn't > > > program > > > our own ID yet but we set the Part Number as 0xd08 (A72). > > > According to my folks, ARM's A53, A57, A72, and A73 designs all > > > have > > > 64B CL. If that's true, can I push a patch to make the change? > > > > Yes. Broadcom Stingray has the same situation i.e Use > > flags_generic, > > machine_args_generic > > > This will solve only the native compilation issue. It will not > address distro compilation (may be this is not your goal?). See above. > > > > Please comment. > > > > > > > > > Thanks, > > > Yongseok > > >
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
> > On Fri, 2019-01-04 at 19:59 +, Yongseok Koh wrote: > > --- > > --- > > Hi, > > > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set to be > > 128B by default. Mellanox's BlueField is an ARM CPU having Cortex-A72 > > and its CL size is 64B. Just wondering how many devices are out there with 128B cache line? I also have not heard about any future devices with 128B cache line. If the majority is 64B, why not keep 64B as the default? > > > > I can add config/defconfig_arm64-bluefield-linuxapp-gcc for legacy > > build anyway. > > > > Makes sense. > > > For the meson build, I know it parses the Main ID register to figure > > out Implementor ID and Part Number. However, Mellanox doesn't program > > our own ID yet but we set the Part Number as 0xd08 (A72). > > According to my folks, ARM's A53, A57, A72, and A73 designs all have > > 64B CL. If that's true, can I push a patch to make the change? > > Yes. Broadcom Stingray has the same situation i.e Use flags_generic, > machine_args_generic > This will solve only the native compilation issue. It will not address distro compilation (may be this is not your goal?). > > > > Please comment. > > > > > > Thanks, > > Yongseok > >
Re: [dpdk-dev] [EXT] Default cacheline size for ARM
On Fri, 2019-01-04 at 19:59 +, Yongseok Koh wrote: > --- > --- > Hi, > > The cacheline size (RTE_CACHE_LINE_SIZE) for ARM CPUs is set to be > 128B by > default. Mellanox's BlueField is an ARM CPU having Cortex-A72 and its > CL size is > 64B. > > I can add config/defconfig_arm64-bluefield-linuxapp-gcc for legacy > build anyway. > Makes sense. > For the meson build, I know it parses the Main ID register to figure > out > Implementor ID and Part Number. However, Mellanox doesn't program our > own ID yet > but we set the Part Number as 0xd08 (A72). > According to my folks, ARM's A53, A57, A72, and A73 designs all have > 64B CL. If > that's true, can I push a patch to make the change? Yes. Broadcom Stingray has the same situation i.e Use flags_generic, machine_args_generic > > Please comment. > > > Thanks, > Yongseok >
