* [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm
@ 2015-11-27 13:34 Jerin Jacob
2015-11-27 13:34 ` [PATCH v3 1/2] config: arm64: create common arm64 configs under common_arm64 file Jerin Jacob
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Jerin Jacob @ 2015-11-27 13:34 UTC (permalink / raw)
To: dev
v1..v2
created common arm64 configs under common_arm64 file.
let each armv8 machine targets capture only the differences
between the common arm64 config.
v2..v3
Fix whitespace issue with git am
Jerin Jacob (2):
config: arm64: create common arm64 configs under common_arm64 file
config: disable CONFIG_RTE_SCHED_VECTOR for arm
config/common_arm64 | 49 ++++++++++++++++++++++++++++
config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
config/defconfig_arm64-armv8a-linuxapp-gcc | 18 +---------
config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +---------
config/defconfig_arm64-xgene1-linuxapp-gcc | 18 +---------
5 files changed, 53 insertions(+), 51 deletions(-)
create mode 100644 config/common_arm64
--
2.1.0
^ permalink raw reply [flat|nested] 16+ messages in thread* [PATCH v3 1/2] config: arm64: create common arm64 configs under common_arm64 file 2015-11-27 13:34 [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob @ 2015-11-27 13:34 ` Jerin Jacob 2015-11-27 13:34 ` [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Jerin Jacob @ 2015-11-27 13:34 UTC (permalink / raw) To: dev let each armv8 machine targets capture only the differences between the common arm64 config. Suggested-by: Thomas Monjalon <thomas.monjalon@6wind.com> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> --- config/common_arm64 | 48 ++++++++++++++++++++++++++++ config/defconfig_arm64-armv8a-linuxapp-gcc | 18 +---------- config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +---------- config/defconfig_arm64-xgene1-linuxapp-gcc | 18 +---------- 4 files changed, 51 insertions(+), 51 deletions(-) create mode 100644 config/common_arm64 diff --git a/config/common_arm64 b/config/common_arm64 new file mode 100644 index 0000000..5e5e303 --- /dev/null +++ b/config/common_arm64 @@ -0,0 +1,48 @@ +# BSD LICENSE +# +# Copyright (C) Cavium networks 2015. All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Cavium networks nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +# + + +CONFIG_RTE_ARCH="arm64" +CONFIG_RTE_ARCH_ARM64=y +CONFIG_RTE_ARCH_64=y +CONFIG_RTE_ARCH_ARM_NEON=y + +CONFIG_RTE_FORCE_INTRINSICS=y + +CONFIG_RTE_IXGBE_INC_VECTOR=n +CONFIG_RTE_LIBRTE_VIRTIO_PMD=n +CONFIG_RTE_LIBRTE_IVSHMEM=n +CONFIG_RTE_LIBRTE_FM10K_PMD=n +CONFIG_RTE_LIBRTE_I40E_PMD=n + +CONFIG_RTE_LIBRTE_LPM=n +CONFIG_RTE_LIBRTE_TABLE=n +CONFIG_RTE_LIBRTE_PIPELINE=n diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc index 49e7056..39e36b8 100644 --- a/config/defconfig_arm64-armv8a-linuxapp-gcc +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc @@ -30,27 +30,11 @@ # #include "common_linuxapp" +#include "common_arm64" CONFIG_RTE_MACHINE="armv8a" -CONFIG_RTE_ARCH="arm64" -CONFIG_RTE_ARCH_ARM64=y -CONFIG_RTE_ARCH_64=y -CONFIG_RTE_ARCH_ARM_NEON=y - -CONFIG_RTE_FORCE_INTRINSICS=y - CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y CONFIG_RTE_CACHE_LINE_SIZE=64 - -CONFIG_RTE_IXGBE_INC_VECTOR=n -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n -CONFIG_RTE_LIBRTE_IVSHMEM=n -CONFIG_RTE_LIBRTE_FM10K_PMD=n -CONFIG_RTE_LIBRTE_I40E_PMD=n - -CONFIG_RTE_LIBRTE_LPM=n -CONFIG_RTE_LIBRTE_TABLE=n -CONFIG_RTE_LIBRTE_PIPELINE=n diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc index 6b2048b..d63d9b8 100644 --- a/config/defconfig_arm64-thunderx-linuxapp-gcc +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc @@ -30,27 +30,11 @@ # #include "common_linuxapp" +#include "common_arm64" CONFIG_RTE_MACHINE="thunderx" -CONFIG_RTE_ARCH="arm64" -CONFIG_RTE_ARCH_ARM64=y -CONFIG_RTE_ARCH_64=y -CONFIG_RTE_ARCH_ARM_NEON=y - -CONFIG_RTE_FORCE_INTRINSICS=y - CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y CONFIG_RTE_CACHE_LINE_SIZE=128 - -CONFIG_RTE_IXGBE_INC_VECTOR=n -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n -CONFIG_RTE_LIBRTE_IVSHMEM=n -CONFIG_RTE_LIBRTE_FM10K_PMD=n -CONFIG_RTE_LIBRTE_I40E_PMD=n - -CONFIG_RTE_LIBRTE_LPM=n -CONFIG_RTE_LIBRTE_TABLE=n -CONFIG_RTE_LIBRTE_PIPELINE=n diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc b/config/defconfig_arm64-xgene1-linuxapp-gcc index d75f8f0..0759721 100644 --- a/config/defconfig_arm64-xgene1-linuxapp-gcc +++ b/config/defconfig_arm64-xgene1-linuxapp-gcc @@ -30,27 +30,11 @@ # #include "common_linuxapp" +#include "common_arm64" CONFIG_RTE_MACHINE="xgene1" -CONFIG_RTE_ARCH="arm64" -CONFIG_RTE_ARCH_ARM64=y -CONFIG_RTE_ARCH_64=y -CONFIG_RTE_ARCH_ARM_NEON=y - -CONFIG_RTE_FORCE_INTRINSICS=y - CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y CONFIG_RTE_CACHE_LINE_SIZE=64 - -CONFIG_RTE_IXGBE_INC_VECTOR=n -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n -CONFIG_RTE_LIBRTE_IVSHMEM=n -CONFIG_RTE_LIBRTE_FM10K_PMD=n -CONFIG_RTE_LIBRTE_I40E_PMD=n - -CONFIG_RTE_LIBRTE_LPM=n -CONFIG_RTE_LIBRTE_TABLE=n -CONFIG_RTE_LIBRTE_PIPELINE=n -- 2.1.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-27 13:34 [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob 2015-11-27 13:34 ` [PATCH v3 1/2] config: arm64: create common arm64 configs under common_arm64 file Jerin Jacob @ 2015-11-27 13:34 ` Jerin Jacob 2015-11-27 14:36 ` Jan Viktorin 2015-11-29 23:48 ` Jianbo Liu 2015-11-27 14:40 ` [PATCH v3 0/2] " Jan Viktorin 2015-11-30 16:37 ` Stephen Hemminger 3 siblings, 2 replies; 16+ messages in thread From: Jerin Jacob @ 2015-11-27 13:34 UTC (permalink / raw) To: dev Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR does support only SSE intrinsic, so disable it till we have neon support. Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> --- config/common_arm64 | 1 + config/defconfig_arm-armv7a-linuxapp-gcc | 1 + 2 files changed, 2 insertions(+) diff --git a/config/common_arm64 b/config/common_arm64 index 5e5e303..d6a9cb9 100644 --- a/config/common_arm64 +++ b/config/common_arm64 @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n CONFIG_RTE_LIBRTE_LPM=n CONFIG_RTE_LIBRTE_TABLE=n CONFIG_RTE_LIBRTE_PIPELINE=n +CONFIG_RTE_SCHED_VECTOR=n diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc index 82143af..9924ff9 100644 --- a/config/defconfig_arm-armv7a-linuxapp-gcc +++ b/config/defconfig_arm-armv7a-linuxapp-gcc @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n CONFIG_RTE_LIBRTE_LPM=n CONFIG_RTE_LIBRTE_TABLE=n CONFIG_RTE_LIBRTE_PIPELINE=n +CONFIG_RTE_SCHED_VECTOR=n # cannot use those on ARM CONFIG_RTE_KNI_KMOD=n -- 2.1.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-27 13:34 ` [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob @ 2015-11-27 14:36 ` Jan Viktorin 2015-11-29 23:48 ` Jianbo Liu 1 sibling, 0 replies; 16+ messages in thread From: Jan Viktorin @ 2015-11-27 14:36 UTC (permalink / raw) To: Jerin Jacob; +Cc: dev Acked-By: Jan Viktorin <viktorin@rehivetech.com> On Fri, 27 Nov 2015 19:04:28 +0530 Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote: > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > does support only SSE intrinsic, so disable it till we have neon support. > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > --- > config/common_arm64 | 1 + > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/config/common_arm64 b/config/common_arm64 > index 5e5e303..d6a9cb9 100644 > --- a/config/common_arm64 > +++ b/config/common_arm64 > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > CONFIG_RTE_LIBRTE_LPM=n > CONFIG_RTE_LIBRTE_TABLE=n > CONFIG_RTE_LIBRTE_PIPELINE=n > +CONFIG_RTE_SCHED_VECTOR=n > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > index 82143af..9924ff9 100644 > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > CONFIG_RTE_LIBRTE_LPM=n > CONFIG_RTE_LIBRTE_TABLE=n > CONFIG_RTE_LIBRTE_PIPELINE=n > +CONFIG_RTE_SCHED_VECTOR=n > > # cannot use those on ARM > CONFIG_RTE_KNI_KMOD=n ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-27 13:34 ` [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob 2015-11-27 14:36 ` Jan Viktorin @ 2015-11-29 23:48 ` Jianbo Liu 2015-11-30 5:47 ` Jerin Jacob 1 sibling, 1 reply; 16+ messages in thread From: Jianbo Liu @ 2015-11-29 23:48 UTC (permalink / raw) To: Jerin Jacob; +Cc: dev On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote: > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > does support only SSE intrinsic, so disable it till we have neon support. > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > --- > config/common_arm64 | 1 + > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/config/common_arm64 b/config/common_arm64 > index 5e5e303..d6a9cb9 100644 > --- a/config/common_arm64 > +++ b/config/common_arm64 > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > CONFIG_RTE_LIBRTE_LPM=n > CONFIG_RTE_LIBRTE_TABLE=n > CONFIG_RTE_LIBRTE_PIPELINE=n > +CONFIG_RTE_SCHED_VECTOR=n > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > index 82143af..9924ff9 100644 > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > CONFIG_RTE_LIBRTE_LPM=n > CONFIG_RTE_LIBRTE_TABLE=n > CONFIG_RTE_LIBRTE_PIPELINE=n > +CONFIG_RTE_SCHED_VECTOR=n > > # cannot use those on ARM > CONFIG_RTE_KNI_KMOD=n > -- > 2.1.0 > Hi Jerin, In this way, we still have to modify two files each time a new feature is added but not verified on ARM architectures. Since disabling those drivers and libs are common for both armv7 and armv8, can you put them in one config file, for example: common_arm? It is not like common_arm64, which is solely for armv8 platform. Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc you can include it in the thunderx or xgene1 config files respectively, and overriding some special config if needed. On the other hand, If we support the features in the future by replacing SSE intrinsic with NEON, we just need to remove the lines in one place. Regards, Jianbo ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-29 23:48 ` Jianbo Liu @ 2015-11-30 5:47 ` Jerin Jacob 2015-11-30 17:03 ` Jianbo Liu 0 siblings, 1 reply; 16+ messages in thread From: Jerin Jacob @ 2015-11-30 5:47 UTC (permalink / raw) To: Jianbo Liu; +Cc: dev On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote: > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote: > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > > does support only SSE intrinsic, so disable it till we have neon support. > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > --- > > config/common_arm64 | 1 + > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/config/common_arm64 b/config/common_arm64 > > index 5e5e303..d6a9cb9 100644 > > --- a/config/common_arm64 > > +++ b/config/common_arm64 > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > > CONFIG_RTE_LIBRTE_LPM=n > > CONFIG_RTE_LIBRTE_TABLE=n > > CONFIG_RTE_LIBRTE_PIPELINE=n > > +CONFIG_RTE_SCHED_VECTOR=n > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > > index 82143af..9924ff9 100644 > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > > CONFIG_RTE_LIBRTE_LPM=n > > CONFIG_RTE_LIBRTE_TABLE=n > > CONFIG_RTE_LIBRTE_PIPELINE=n > > +CONFIG_RTE_SCHED_VECTOR=n > > > > # cannot use those on ARM > > CONFIG_RTE_KNI_KMOD=n > > -- > > 2.1.0 > > > > Hi Jerin, Hi Jianbo, Thanks for the review. Looking forward to seeing contributions to DPDK-ARM. We definitely need more hands to make best DPDK-ARM port. > In this way, we still have to modify two files each time a new feature > is added but not verified on ARM architectures. > Since disabling those drivers and libs are common for both armv7 and > armv8, can you put them in one config file, for example: common_arm? I initially thought of making it a single common_arm file, Then later I realized that it may not be worth as, 1) If a new feature added to DPDK which has the dependency on SSE then implementer has to disable on "n" platforms(tile, powerpc..).By unifying single arm config will make it "n-1" so it's like "n" vs "n-1" not "n" vs "2n" 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet unlike ARMv8. Till we have PCI NIC PMD support, armv7 config needs to be updated for each and every new PMD inclusion. 3) neon capabilities are bit different in ARMv7 and ARMv8. For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used in implementing ACL-NEON. i.e Need additional efforts to extend the armv8 neon code to armv7(or vice versa).So it's better to have fine control on the config file to enable selective features 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0 runs ? optional features like armv8 crypto instruction support or not? It's armv8 v1 or v2 ? atomic instruction support for not? its a long list 4)I would like to see ARM configs as different config like i686, X86_64 in DPDK > It is not like common_arm64, which is solely for armv8 platform. > Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc I thought so, Then I realized that we may have FreeBSD, arm compiler, clang, llvm support in future. > you can include it in the thunderx or xgene1 config files respectively, > and overriding some special config if needed. Agree. existing patch addresses this > > On the other hand, If we support the features in the future by > replacing SSE intrinsic with NEON, we just need to remove the lines in one place. See point 3 above, I feel rather than coming with the framework to fix the exceptions it's better to fix the exceptions its self. I am planning to send out next patch by today for supporting CONFIG_RTE_LIBRTE_LPM,CONFIG_RTE_LIBRTE_TABLE,CONFIG_RTE_LIBRTE_PIPELINE. i.e only a few entries will be common. Please find below the list, the reason for setting as "n" for armv7 and armv8 is different. lack of PCI PMD supports vs SIMD support. CONFIG_RTE_IXGBE_INC_VECTOR=n CONFIG_RTE_LIBRTE_VIRTIO_PMD=n CONFIG_RTE_LIBRTE_IVSHMEM=n CONFIG_RTE_LIBRTE_FM10K_PMD=n CONFIG_RTE_LIBRTE_I40E_PMD=n - Jerin > > Regards, > Jianbo ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 5:47 ` Jerin Jacob @ 2015-11-30 17:03 ` Jianbo Liu 2015-11-30 10:22 ` Jerin Jacob 0 siblings, 1 reply; 16+ messages in thread From: Jianbo Liu @ 2015-11-30 17:03 UTC (permalink / raw) To: Jerin Jacob; +Cc: dev On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote: > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote: > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote: > > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > > > does support only SSE intrinsic, so disable it till we have neon support. > > > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > > --- > > > config/common_arm64 | 1 + > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > > > 2 files changed, 2 insertions(+) > > > > > > diff --git a/config/common_arm64 b/config/common_arm64 > > > index 5e5e303..d6a9cb9 100644 > > > --- a/config/common_arm64 > > > +++ b/config/common_arm64 > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > > > CONFIG_RTE_LIBRTE_LPM=n > > > CONFIG_RTE_LIBRTE_TABLE=n > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > +CONFIG_RTE_SCHED_VECTOR=n > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > > > index 82143af..9924ff9 100644 > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > > > CONFIG_RTE_LIBRTE_LPM=n > > > CONFIG_RTE_LIBRTE_TABLE=n > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > > > # cannot use those on ARM > > > CONFIG_RTE_KNI_KMOD=n > > > -- > > > 2.1.0 > > > > > > > Hi Jerin, > > Hi Jianbo, Thanks for the review. > Looking forward to seeing contributions to DPDK-ARM. > We definitely need more hands to make best DPDK-ARM port. > > > In this way, we still have to modify two files each time a new feature > > is added but not verified on ARM architectures. > > Since disabling those drivers and libs are common for both armv7 and > > armv8, can you put them in one config file, for example: common_arm? > > I initially thought of making it a single common_arm file, Then > later I realized that it may not be worth as, > > 1) If a new feature added to DPDK which has the dependency on SSE then > implementer has to disable on "n" platforms(tile, powerpc..).By unifying > single arm config will make it "n-1" so it's like "n" vs "n-1" not "n" > vs "2n" I'm talking about your patch, which is for ARM platform only. And the two files we need to modify are armv7 and armv8 configs. If you want to include other platforms, your patch is still incomplete :) > > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet > unlike ARMv8. > Till we have PCI NIC PMD support, armv7 config needs to be updated > for each and every new PMD inclusion. > > 3) neon capabilities are bit different in ARMv7 and ARMv8. > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used > in implementing ACL-NEON. i.e Need additional efforts to extend > the armv8 neon code to armv7(or vice versa).So it's better to > have fine control on the config file to enable selective features > The differences between ARMv7 and ARMv8 can't justify we only add new config for ARMv8. And this file is trying to disable drivers and libs which is not supported on ARM platforms for now. > 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION > DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0 > runs ? optional features like armv8 crypto instruction support or not? > It's armv8 v1 or v2 ? atomic instruction support for not? its a long > list > I think these "IMPLEMENTATION DEFINED" features should be configured in the different platform (machine) config files. Can this common_arm64 solve your concern? > 4)I would like to see ARM configs as different config like i686, X86_64 > in DPDK > Basically, we need to use the default common_linux/bsd to enable the new-added features in DPDK. > > > It is not like common_arm64, which is solely for armv8 platform. > > Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc > > I thought so, Then I realized that we may have > FreeBSD, arm compiler, clang, llvm support in future. > > > you can include it in the thunderx or xgene1 config files respectively, > > and overriding some special config if needed. > > Agree. existing patch addresses this > If there exists a defconfig_arm64-armv8a-linuxapp-gcc, why needs to add a new file(common_arm64) in your patch? The defconfig_arm64-armv8a-xxx-xxx can be treated as a config for a common ARMv8 platform, and one which other specific ARMv8 platforms can base on. > > > > On the other hand, If we support the features in the future by > > replacing SSE intrinsic with NEON, we just need to remove the lines in one place. > > See point 3 above, > > I feel rather than coming with the framework to fix the exceptions it's > better to fix the exceptions its self. > I am planning to send out next patch by today for supporting > CONFIG_RTE_LIBRTE_LPM,CONFIG_RTE_LIBRTE_TABLE,CONFIG_RTE_LIBRTE_PIPELINE. > > i.e only a few entries will be common. Please find below the list, > the reason for setting as "n" for armv7 and armv8 is different. > lack of PCI PMD supports vs SIMD support. > > CONFIG_RTE_IXGBE_INC_VECTOR=n > CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > CONFIG_RTE_LIBRTE_IVSHMEM=n > CONFIG_RTE_LIBRTE_FM10K_PMD=n > CONFIG_RTE_LIBRTE_I40E_PMD=n > Yes, but what if new SSE enhancement is added on x86, we need to add it to the list. > - Jerin > > > > > Regards, > > Jianbo ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 17:03 ` Jianbo Liu @ 2015-11-30 10:22 ` Jerin Jacob 2015-11-30 18:55 ` Jianbo Liu 0 siblings, 1 reply; 16+ messages in thread From: Jerin Jacob @ 2015-11-30 10:22 UTC (permalink / raw) To: Jianbo Liu; +Cc: dev On Mon, Nov 30, 2015 at 12:03:21PM -0500, Jianbo Liu wrote: > On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote: > > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote: > > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote: > > > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > > > > does support only SSE intrinsic, so disable it till we have neon support. > > > > > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > > > --- > > > > config/common_arm64 | 1 + > > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > > > > 2 files changed, 2 insertions(+) > > > > > > > > diff --git a/config/common_arm64 b/config/common_arm64 > > > > index 5e5e303..d6a9cb9 100644 > > > > --- a/config/common_arm64 > > > > +++ b/config/common_arm64 > > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > > > > CONFIG_RTE_LIBRTE_LPM=n > > > > CONFIG_RTE_LIBRTE_TABLE=n > > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > > > > index 82143af..9924ff9 100644 > > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > > > > CONFIG_RTE_LIBRTE_LPM=n > > > > CONFIG_RTE_LIBRTE_TABLE=n > > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > > > > > # cannot use those on ARM > > > > CONFIG_RTE_KNI_KMOD=n > > > > -- > > > > 2.1.0 > > > > > > > > > > Hi Jerin, > > > > Hi Jianbo, Thanks for the review. > > Looking forward to seeing contributions to DPDK-ARM. > > We definitely need more hands to make best DPDK-ARM port. > > > > > In this way, we still have to modify two files each time a new feature > > > is added but not verified on ARM architectures. > > > Since disabling those drivers and libs are common for both armv7 and > > > armv8, can you put them in one config file, for example: common_arm? > > > > I initially thought of making it a single common_arm file, Then > > later I realized that it may not be worth as, > > > > 1) If a new feature added to DPDK which has the dependency on SSE then > > implementer has to disable on "n" platforms(tile, powerpc..).By unifying > > single arm config will make it "n-1" so it's like "n" vs "n-1" not "n" > > vs "2n" > > I'm talking about your patch, which is for ARM platform only. And the > two files we need to modify are armv7 and armv8 configs. > If you want to include other platforms, your patch is still incomplete :) > That was the reply for the concern you have raised for the new feature. Not specific to my patch. My patch is complete, as I have checked other platforms before sending the patch they have already disabled the sched library :-) > > > > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet > > unlike ARMv8. > > Till we have PCI NIC PMD support, armv7 config needs to be updated > > for each and every new PMD inclusion. > > > > 3) neon capabilities are bit different in ARMv7 and ARMv8. > > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used > > in implementing ACL-NEON. i.e Need additional efforts to extend > > the armv8 neon code to armv7(or vice versa).So it's better to > > have fine control on the config file to enable selective features > > > > The differences between ARMv7 and ARMv8 can't justify we only add new > config for ARMv8. And this file is trying to disable drivers and libs > which is not supported on ARM platforms for now. > I thought difference and point 3 should justify the need for different config. No? > > 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION > > DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0 > > runs ? optional features like armv8 crypto instruction support or not? > > It's armv8 v1 or v2 ? atomic instruction support for not? its a long > > list > > > > I think these "IMPLEMENTATION DEFINED" features should be configured > in the different platform (machine) config files. Can this > common_arm64 solve your concern? Yes, "IMPLEMENTATION DEFINED" features of armv8(default behavior in common_arm64). I think it makes sense not mix with armv7. > > > 4)I would like to see ARM configs as different config like i686, X86_64 > > in DPDK > > > > Basically, we need to use the default common_linux/bsd to enable the > new-added features in DPDK. > > > > > > It is not like common_arm64, which is solely for armv8 platform. > > > Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc > > > > I thought so, Then I realized that we may have > > FreeBSD, arm compiler, clang, llvm support in future. > > > > > you can include it in the thunderx or xgene1 config files respectively, > > > and overriding some special config if needed. > > > > Agree. existing patch addresses this > > > > If there exists a defconfig_arm64-armv8a-linuxapp-gcc, why needs to > add a new file(common_arm64) in your patch? > The defconfig_arm64-armv8a-xxx-xxx can be treated as a config for a > common ARMv8 platform, and one which other specific ARMv8 platforms > can base on. > I was thinking to have the common_arm64 file so that "FreeBSD, arm compiler, clang, llvm" future version can include it directly. But I agree with you. defconfig_arm64-armv8a-linuxapp-gcc can be treated as a config for a common file for defconfig_arm64-*-linuxapp-gcc(anyway its same, just the toolchain added in defconfig_arm64-*-linuxapp-gcc) I will send out new version with defconfig_arm64-armv8a-linuxapp-gcc as the base instead of common_arm64 file. > > > > > > On the other hand, If we support the features in the future by > > > replacing SSE intrinsic with NEON, we just need to remove the lines in one place. > > > > See point 3 above, > > > > I feel rather than coming with the framework to fix the exceptions it's > > better to fix the exceptions its self. > > I am planning to send out next patch by today for supporting > > CONFIG_RTE_LIBRTE_LPM,CONFIG_RTE_LIBRTE_TABLE,CONFIG_RTE_LIBRTE_PIPELINE. > > > > i.e only a few entries will be common. Please find below the list, > > the reason for setting as "n" for armv7 and armv8 is different. > > lack of PCI PMD supports vs SIMD support. > > > > CONFIG_RTE_IXGBE_INC_VECTOR=n > > CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > > CONFIG_RTE_LIBRTE_IVSHMEM=n > > CONFIG_RTE_LIBRTE_FM10K_PMD=n > > CONFIG_RTE_LIBRTE_I40E_PMD=n > > > > Yes, but what if new SSE enhancement is added on x86, we need to add > it to the list. CONFIG_RTE_IXGBE_INC_VECTOR=n CONFIG_RTE_LIBRTE_VIRTIO_PMD=n CONFIG_RTE_LIBRTE_IVSHMEM=n CONFIG_RTE_LIBRTE_FM10K_PMD=n CONFIG_RTE_LIBRTE_I40E_PMD=n IMO, creating a config file with above as "common_arm" file doesn't make sense to me. It looks odd and we are not there because functional difference in current ARMv7 and ARMv8 port. Feel free to submit the RFC patch if you think it makes sense. Let me know your plan. I can hold off my v4 for "updating defconfig_arm64-armv8a-linuxapp-gcc as base instead of common_arm64 file" > > > - Jerin > > > > > > > > Regards, > > > Jianbo ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 10:22 ` Jerin Jacob @ 2015-11-30 18:55 ` Jianbo Liu 2015-11-30 13:27 ` Jan Viktorin 0 siblings, 1 reply; 16+ messages in thread From: Jianbo Liu @ 2015-11-30 18:55 UTC (permalink / raw) To: Jerin Jacob; +Cc: dev On Mon, Nov 30, 2015 at 03:52:31PM +0530, Jerin Jacob wrote: > On Mon, Nov 30, 2015 at 12:03:21PM -0500, Jianbo Liu wrote: > > On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote: > > > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote: > > > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote: > > > > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > > > > > does support only SSE intrinsic, so disable it till we have neon support. > > > > > > > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > > > > --- > > > > > config/common_arm64 | 1 + > > > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > > > > > 2 files changed, 2 insertions(+) > > > > > > > > > > diff --git a/config/common_arm64 b/config/common_arm64 > > > > > index 5e5e303..d6a9cb9 100644 > > > > > --- a/config/common_arm64 > > > > > +++ b/config/common_arm64 > > > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > > > > > CONFIG_RTE_LIBRTE_LPM=n > > > > > CONFIG_RTE_LIBRTE_TABLE=n > > > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > > > > > index 82143af..9924ff9 100644 > > > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > > > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > > > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > > > > > CONFIG_RTE_LIBRTE_LPM=n > > > > > CONFIG_RTE_LIBRTE_TABLE=n > > > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > > > > > > > # cannot use those on ARM > > > > > CONFIG_RTE_KNI_KMOD=n > > > > > -- > > > > > 2.1.0 > > > > > > > > > > > > > Hi Jerin, > > > > > > Hi Jianbo, Thanks for the review. > > > Looking forward to seeing contributions to DPDK-ARM. > > > We definitely need more hands to make best DPDK-ARM port. > > > > > > > In this way, we still have to modify two files each time a new feature > > > > is added but not verified on ARM architectures. > > > > Since disabling those drivers and libs are common for both armv7 and > > > > armv8, can you put them in one config file, for example: common_arm? > > > > > > I initially thought of making it a single common_arm file, Then > > > later I realized that it may not be worth as, > > > > > > 1) If a new feature added to DPDK which has the dependency on SSE then > > > implementer has to disable on "n" platforms(tile, powerpc..).By unifying > > > single arm config will make it "n-1" so it's like "n" vs "n-1" not "n" > > > vs "2n" > > > > I'm talking about your patch, which is for ARM platform only. And the > > two files we need to modify are armv7 and armv8 configs. > > If you want to include other platforms, your patch is still incomplete :) > > > > That was the reply for the concern you have raised for the new feature. > Not specific to my patch. My patch is complete, as I have > checked other platforms before sending the patch > they have already disabled the sched library :-) > > > > > > > > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet > > > unlike ARMv8. > > > Till we have PCI NIC PMD support, armv7 config needs to be updated > > > for each and every new PMD inclusion. > > > > > > 3) neon capabilities are bit different in ARMv7 and ARMv8. > > > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used > > > in implementing ACL-NEON. i.e Need additional efforts to extend > > > the armv8 neon code to armv7(or vice versa).So it's better to > > > have fine control on the config file to enable selective features > > > > > > > The differences between ARMv7 and ARMv8 can't justify we only add new > > config for ARMv8. And this file is trying to disable drivers and libs > > which is not supported on ARM platforms for now. > > > > I thought difference and point 3 should justify the need for different config. No? > > > > > 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION > > > DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0 > > > runs ? optional features like armv8 crypto instruction support or not? > > > It's armv8 v1 or v2 ? atomic instruction support for not? its a long > > > list > > > > > > > I think these "IMPLEMENTATION DEFINED" features should be configured > > in the different platform (machine) config files. Can this > > common_arm64 solve your concern? > > Yes, "IMPLEMENTATION DEFINED" features of armv8(default behavior in > common_arm64). I think it makes sense not mix with armv7. > > > > > > 4)I would like to see ARM configs as different config like i686, X86_64 > > > in DPDK > > > > > > > Basically, we need to use the default common_linux/bsd to enable the > > new-added features in DPDK. > > > > > > > > > It is not like common_arm64, which is solely for armv8 platform. > > > > Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc > > > > > > I thought so, Then I realized that we may have > > > FreeBSD, arm compiler, clang, llvm support in future. > > > > > > > you can include it in the thunderx or xgene1 config files respectively, > > > > and overriding some special config if needed. > > > > > > Agree. existing patch addresses this > > > > > > > If there exists a defconfig_arm64-armv8a-linuxapp-gcc, why needs to > > add a new file(common_arm64) in your patch? > > The defconfig_arm64-armv8a-xxx-xxx can be treated as a config for a > > common ARMv8 platform, and one which other specific ARMv8 platforms > > can base on. > > > > I was thinking to have the common_arm64 file so that "FreeBSD, arm compiler, > clang, llvm" future version can include it directly. > But I agree with you. defconfig_arm64-armv8a-linuxapp-gcc can be treated as a > config for a common file for defconfig_arm64-*-linuxapp-gcc(anyway its same, > just the toolchain added in defconfig_arm64-*-linuxapp-gcc) > I will send out new version with defconfig_arm64-armv8a-linuxapp-gcc > as the base instead of common_arm64 file. > > > > > > > > > > > On the other hand, If we support the features in the future by > > > > replacing SSE intrinsic with NEON, we just need to remove the lines in one place. > > > > > > See point 3 above, > > > > > > I feel rather than coming with the framework to fix the exceptions it's > > > better to fix the exceptions its self. > > > I am planning to send out next patch by today for supporting > > > CONFIG_RTE_LIBRTE_LPM,CONFIG_RTE_LIBRTE_TABLE,CONFIG_RTE_LIBRTE_PIPELINE. > > > > > > i.e only a few entries will be common. Please find below the list, > > > the reason for setting as "n" for armv7 and armv8 is different. > > > lack of PCI PMD supports vs SIMD support. > > > > > > CONFIG_RTE_IXGBE_INC_VECTOR=n > > > CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > > > CONFIG_RTE_LIBRTE_IVSHMEM=n > > > CONFIG_RTE_LIBRTE_FM10K_PMD=n > > > CONFIG_RTE_LIBRTE_I40E_PMD=n > > > > > > > Yes, but what if new SSE enhancement is added on x86, we need to add > > it to the list. > > CONFIG_RTE_IXGBE_INC_VECTOR=n > CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > CONFIG_RTE_LIBRTE_IVSHMEM=n > CONFIG_RTE_LIBRTE_FM10K_PMD=n > CONFIG_RTE_LIBRTE_I40E_PMD=n > > IMO, creating a config file with above as "common_arm" file > doesn't make sense to me. It looks odd and we are not there because > functional difference in current ARMv7 and ARMv8 port. > Feel free to submit the RFC patch if you think it makes sense. > > Let me know your plan. I can hold off my v4 for "updating > defconfig_arm64-armv8a-linuxapp-gcc as base instead of common_arm64 file" > I understand your concern about ARMv7 and ARMv8 differencs, We can talk that later. For now, please continue your v4 patch. Besides, I don't like "common_arm" either. If there must be, it should be called backlists, and provided globally by DPDK for all non-x86 platform :) > > > > > > - Jerin > > > > > > > > > > > Regards, > > > > Jianbo ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 18:55 ` Jianbo Liu @ 2015-11-30 13:27 ` Jan Viktorin 2015-11-30 13:59 ` Thomas Monjalon 0 siblings, 1 reply; 16+ messages in thread From: Jan Viktorin @ 2015-11-30 13:27 UTC (permalink / raw) To: Jianbo Liu; +Cc: dev On Mon, 30 Nov 2015 13:55:45 -0500 Jianbo Liu <jianbo.liu@linaro.org> wrote: > On Mon, Nov 30, 2015 at 03:52:31PM +0530, Jerin Jacob wrote: > > On Mon, Nov 30, 2015 at 12:03:21PM -0500, Jianbo Liu wrote: > > > On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote: > > > > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote: > > > > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote: > > > > > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR > > > > > > does support only SSE intrinsic, so disable it till we have neon support. > > > > > > > > > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config") > > > > > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > > > > > > --- > > > > > > config/common_arm64 | 1 + > > > > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > > > > > > 2 files changed, 2 insertions(+) > > > > > > > > > > > > diff --git a/config/common_arm64 b/config/common_arm64 > > > > > > index 5e5e303..d6a9cb9 100644 > > > > > > --- a/config/common_arm64 > > > > > > +++ b/config/common_arm64 > > > > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n > > > > > > CONFIG_RTE_LIBRTE_LPM=n > > > > > > CONFIG_RTE_LIBRTE_TABLE=n > > > > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > > > > > > index 82143af..9924ff9 100644 > > > > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > > > > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > > > > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n > > > > > > CONFIG_RTE_LIBRTE_LPM=n > > > > > > CONFIG_RTE_LIBRTE_TABLE=n > > > > > > CONFIG_RTE_LIBRTE_PIPELINE=n > > > > > > +CONFIG_RTE_SCHED_VECTOR=n > > > > > > > > > > > > # cannot use those on ARM > > > > > > CONFIG_RTE_KNI_KMOD=n > > > > > > -- > > > > > > 2.1.0 > > > > > > > > > > > > > > > > Hi Jerin, > > > > > > > > Hi Jianbo, Thanks for the review. > > > > Looking forward to seeing contributions to DPDK-ARM. > > > > We definitely need more hands to make best DPDK-ARM port. > > > > > > > > > In this way, we still have to modify two files each time a new feature > > > > > is added but not verified on ARM architectures. > > > > > Since disabling those drivers and libs are common for both armv7 and > > > > > armv8, can you put them in one config file, for example: common_arm? Hello Jerin and Jianbo. Do you think that changing a single line in two files (instead of a single single) is really an issue? I don't think so. At least for now. I believe (and have already expressed this idea) that this is not a problem of architecture ports but it is a problem of the build system. Love me or hate me, in my opinion the build system is broken :). The build system should be able to solve this. I've created privately an integration of kconfig into DPDK, however, it is far from being usable and I did not have time to make at least an RFC patch. If there is an attitude in the community to include such thing in the future versions, I'd like to make some more effort in this area. For now, the separate armv7/armv8 configuration seems OK to me. > > > > > > > > [snip] > > > > > > > > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet > > > > unlike ARMv8. > > > > Till we have PCI NIC PMD support, armv7 config needs to be updated > > > > for each and every new PMD inclusion. Unfortunately yes. I don't like this state very much... > > > > > > > > 3) neon capabilities are bit different in ARMv7 and ARMv8. > > > > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used > > > > in implementing ACL-NEON. i.e Need additional efforts to extend > > > > the armv8 neon code to armv7(or vice versa).So it's better to > > > > have fine control on the config file to enable selective features > > > > > > > > > > The differences between ARMv7 and ARMv8 can't justify we only add new > > > config for ARMv8. And this file is trying to disable drivers and libs > > > which is not supported on ARM platforms for now. > > > > > > > I thought difference and point 3 should justify the need for different config. No? I vote yes. > > [snip] > > > > > > > I was thinking to have the common_arm64 file so that "FreeBSD, arm compiler, > > clang, llvm" future version can include it directly. > > But I agree with you. defconfig_arm64-armv8a-linuxapp-gcc can be treated as a > > config for a common file for defconfig_arm64-*-linuxapp-gcc(anyway its same, > > just the toolchain added in defconfig_arm64-*-linuxapp-gcc) > > I will send out new version with defconfig_arm64-armv8a-linuxapp-gcc > > as the base instead of common_arm64 file. I think that unless we support more compilers/operating systems (and this will take some time), there is no need to consider more general configurations. I agree to stay with the armv[78]-linuxapp-gcc for now. Kind Regards Jan Viktorin ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 13:27 ` Jan Viktorin @ 2015-11-30 13:59 ` Thomas Monjalon 2015-11-30 14:04 ` Jan Viktorin 0 siblings, 1 reply; 16+ messages in thread From: Thomas Monjalon @ 2015-11-30 13:59 UTC (permalink / raw) To: Jan Viktorin; +Cc: dev 2015-11-30 14:27, Jan Viktorin: > I believe (and have already expressed this idea) that this is not a > problem of architecture ports but it is a problem of the build system. > Love me or hate me, in my opinion the build system is broken :). The > build system should be able to solve this. > > I've created privately an integration of kconfig into DPDK, however, it > is far from being usable and I did not have time to make at least an > RFC patch. If there is an attitude in the community to include such > thing in the future versions, I'd like to make some more effort in this > area. If we were integrating kconfig, we should consider kconfig-frontends (http://ymorin.is-a-geek.org/projects/kconfig-frontends). But I'm not sure it is the way to go. You are welcome to open the debate in a dedicated thread by explaining the benefits compared to a configuration script. I think most of the options could be automatically guessed given the target CPU, kernel, libc and compiler. It looks like a scripting task, not a manual configuration (as kconfig provides). But maybe we can mix kconfig and some automatic defaults. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 13:59 ` Thomas Monjalon @ 2015-11-30 14:04 ` Jan Viktorin 2015-11-30 14:13 ` Thomas Monjalon 0 siblings, 1 reply; 16+ messages in thread From: Jan Viktorin @ 2015-11-30 14:04 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev On Mon, 30 Nov 2015 14:59:45 +0100 Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > 2015-11-30 14:27, Jan Viktorin: > > I believe (and have already expressed this idea) that this is not a > > problem of architecture ports but it is a problem of the build system. > > Love me or hate me, in my opinion the build system is broken :). The > > build system should be able to solve this. > > > > I've created privately an integration of kconfig into DPDK, however, it > > is far from being usable and I did not have time to make at least an > > RFC patch. If there is an attitude in the community to include such > > thing in the future versions, I'd like to make some more effort in this > > area. > > If we were integrating kconfig, we should consider kconfig-frontends > (http://ymorin.is-a-geek.org/projects/kconfig-frontends). True, this seems to be the easiest way. I've already used it successfully. > But I'm not sure it is the way to go. You are welcome to open the debate > in a dedicated thread by explaining the benefits compared to a configuration > script. OK. I will consider this. Probably, after the community call... (Or before?) > I think most of the options could be automatically guessed given the target > CPU, kernel, libc and compiler. It looks like a scripting task, not a > manual configuration (as kconfig provides). But maybe we can mix kconfig > and some automatic defaults. > Well, scripting... If you have issues like "feature X" does not work on "platform A" then you need to express this. If you try to script such dependency, I am afraid you always end up with a system of the same or equivalent complexity as the kconfig already has :). We'll see... Regards Jan -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-30 14:04 ` Jan Viktorin @ 2015-11-30 14:13 ` Thomas Monjalon 0 siblings, 0 replies; 16+ messages in thread From: Thomas Monjalon @ 2015-11-30 14:13 UTC (permalink / raw) To: Jan Viktorin; +Cc: dev 2015-11-30 15:04, Jan Viktorin: > On Mon, 30 Nov 2015 14:59:45 +0100 > Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > > 2015-11-30 14:27, Jan Viktorin: > > > I believe (and have already expressed this idea) that this is not a > > > problem of architecture ports but it is a problem of the build system. > > > Love me or hate me, in my opinion the build system is broken :). The > > > build system should be able to solve this. > > > > > > I've created privately an integration of kconfig into DPDK, however, it > > > is far from being usable and I did not have time to make at least an > > > RFC patch. If there is an attitude in the community to include such > > > thing in the future versions, I'd like to make some more effort in this > > > area. > > > > If we were integrating kconfig, we should consider kconfig-frontends > > (http://ymorin.is-a-geek.org/projects/kconfig-frontends). > > True, this seems to be the easiest way. I've already used it > successfully. > > > But I'm not sure it is the way to go. You are welcome to open the debate > > in a dedicated thread by explaining the benefits compared to a configuration > > script. > > OK. I will consider this. Probably, after the community call... (Or > before?) Please take your time. We will better ready to discuss it when the "make install" issue will be solved. > > I think most of the options could be automatically guessed given the target > > CPU, kernel, libc and compiler. It looks like a scripting task, not a > > manual configuration (as kconfig provides). But maybe we can mix kconfig > > and some automatic defaults. > > > > Well, scripting... If you have issues like "feature X" does not work > on "platform A" then you need to express this. If you try to script > such dependency, I am afraid you always end up with a system of the same > or equivalent complexity as the kconfig already has :). We'll see... I'm not speaking about complexity here, but just features. With kconfig, options and dependencies are well described but the defaults are fixed. With a script, you can have some dynamically generated defaults. Please expose the needs and features clearly in another thread. Thanks ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-27 13:34 [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob 2015-11-27 13:34 ` [PATCH v3 1/2] config: arm64: create common arm64 configs under common_arm64 file Jerin Jacob 2015-11-27 13:34 ` [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob @ 2015-11-27 14:40 ` Jan Viktorin 2015-11-27 14:49 ` Thomas Monjalon 2015-11-30 16:37 ` Stephen Hemminger 3 siblings, 1 reply; 16+ messages in thread From: Jan Viktorin @ 2015-11-27 14:40 UTC (permalink / raw) To: Jerin Jacob; +Cc: dev Hello, this what I was talking about at the Userspace Summit in Dublin... Somebody adds a feature or change a default setting and it breaks builds of other configurations and platforms. The current build system in DPDK is really imperfect. Thanks for catching this! Regards Jan V. On Fri, 27 Nov 2015 19:04:26 +0530 Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote: > v1..v2 > created common arm64 configs under common_arm64 file. > let each armv8 machine targets capture only the differences > between the common arm64 config. > > v2..v3 > Fix whitespace issue with git am > > Jerin Jacob (2): > config: arm64: create common arm64 configs under common_arm64 file > config: disable CONFIG_RTE_SCHED_VECTOR for arm > > config/common_arm64 | 49 ++++++++++++++++++++++++++++ > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > config/defconfig_arm64-armv8a-linuxapp-gcc | 18 +--------- > config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +--------- > config/defconfig_arm64-xgene1-linuxapp-gcc | 18 +--------- > 5 files changed, 53 insertions(+), 51 deletions(-) > create mode 100644 config/common_arm64 > -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-27 14:40 ` [PATCH v3 0/2] " Jan Viktorin @ 2015-11-27 14:49 ` Thomas Monjalon 0 siblings, 0 replies; 16+ messages in thread From: Thomas Monjalon @ 2015-11-27 14:49 UTC (permalink / raw) To: Jan Viktorin, Jerin Jacob; +Cc: dev 2015-11-27 15:40, Jan Viktorin: > Hello, > > this what I was talking about at the Userspace Summit in Dublin... > Somebody adds a feature or change a default setting and it breaks > builds of other configurations and platforms. The current build system > in DPDK is really imperfect. The issue is due to enablement of a new feature for every platforms without dependency check. Actually the patch should disable CONFIG_RTE_SCHED_VECTOR for every non-x86 platforms. Another fix is discussed in another thread to disable the feature inside the code if the platform cannot support it (currently AVX is required). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm 2015-11-27 13:34 [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob ` (2 preceding siblings ...) 2015-11-27 14:40 ` [PATCH v3 0/2] " Jan Viktorin @ 2015-11-30 16:37 ` Stephen Hemminger 3 siblings, 0 replies; 16+ messages in thread From: Stephen Hemminger @ 2015-11-30 16:37 UTC (permalink / raw) To: Jerin Jacob; +Cc: dev On Fri, 27 Nov 2015 19:04:26 +0530 Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote: > v1..v2 > created common arm64 configs under common_arm64 file. > let each armv8 machine targets capture only the differences > between the common arm64 config. > > v2..v3 > Fix whitespace issue with git am > > Jerin Jacob (2): > config: arm64: create common arm64 configs under common_arm64 file > config: disable CONFIG_RTE_SCHED_VECTOR for arm > > config/common_arm64 | 49 ++++++++++++++++++++++++++++ > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > config/defconfig_arm64-armv8a-linuxapp-gcc | 18 +--------- > config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +--------- > config/defconfig_arm64-xgene1-linuxapp-gcc | 18 +--------- > 5 files changed, 53 insertions(+), 51 deletions(-) > create mode 100644 config/common_arm64 > Since the RTE_SCHED_VECTOR is lightly tested and doesn't provide really significant performance improvement, it should probably be disabled by default on all platforms. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-11-30 16:36 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-27 13:34 [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob 2015-11-27 13:34 ` [PATCH v3 1/2] config: arm64: create common arm64 configs under common_arm64 file Jerin Jacob 2015-11-27 13:34 ` [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm Jerin Jacob 2015-11-27 14:36 ` Jan Viktorin 2015-11-29 23:48 ` Jianbo Liu 2015-11-30 5:47 ` Jerin Jacob 2015-11-30 17:03 ` Jianbo Liu 2015-11-30 10:22 ` Jerin Jacob 2015-11-30 18:55 ` Jianbo Liu 2015-11-30 13:27 ` Jan Viktorin 2015-11-30 13:59 ` Thomas Monjalon 2015-11-30 14:04 ` Jan Viktorin 2015-11-30 14:13 ` Thomas Monjalon 2015-11-27 14:40 ` [PATCH v3 0/2] " Jan Viktorin 2015-11-27 14:49 ` Thomas Monjalon 2015-11-30 16:37 ` Stephen Hemminger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.