[dpdk-dev] [PATCH 0/2] bugfix for Kunpeng930 SVE compile

[dpdk-dev] [PATCH 0/2] bugfix for Kunpeng930 SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng930 SVE compile.

Chengwen Feng (2):
  config/arm: add non-SVE march for soc kunpeng930
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       |  2 +-
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 3 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH 1/2] config/arm: add non-SVE march for soc kunpeng930

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

This patch adds '-march=armv8.2-a+crypto' before
'-march=armv8.2-a+crypto+sve' so that:
1. If compiler doesn't support '-march=armv8.2-a+crypto+sve', then it
will fallback supports 'armv8.2-a+crypto'.
2. If compiler supports '-march=armv8.2-a+crypto+sve', then it will
compile SVE-related code.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..fe6c29b 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -158,7 +158,7 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'machine_args': ['-march=armv8.2-a+crypto', '-march=armv8.2-a+crypto+sve'],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
-- 
2.8.1

Re: [dpdk-dev] [PATCH 1/2] config/arm: add non-SVE march for soc kunpeng930

[Jerin Jacob]

On Wed, May 12, 2021 at 2:01 PM Chengwen Feng <fengchengwen@huawei.com> wrote:
>
> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> but some compiler doesn't recognize the march because it doesn't
> support sve.

Agree with the problem statement.

+ @Juraj Linkeš

>
> This patch adds '-march=armv8.2-a+crypto' before
> '-march=armv8.2-a+crypto+sve' so that:
> 1. If compiler doesn't support '-march=armv8.2-a+crypto+sve', then it
> will fallback supports 'armv8.2-a+crypto'.
> 2. If compiler supports '-march=armv8.2-a+crypto+sve', then it will
> compile SVE-related code.
>
> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  config/arm/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 3f34ec9..fe6c29b 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -158,7 +158,7 @@ implementer_hisilicon = {
>              ]
>          },
>          '0xd02': {
> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> +            'machine_args': ['-march=armv8.2-a+crypto', '-march=armv8.2-a+crypto+sve'],

I think, this problem not specific to Kunpeng. I think, in order to
have a generic solution,
I think, we need to express something like [[armv8.2-a], [crypto],
[sve]] or so in the code and
any infra code can generate a working combination to avoid duplicating
the combination
manually in code and have some generic solution for all the platforms.

i.e
patch 1: Enable the infrastructure for auto probe based on compiler support.
patch 2: Fix existing machines including the Kunpeng.


>              'flags': [
>                  ['RTE_MACHINE', '"Kunpeng 930"'],
>                  ['RTE_ARM_FEATURE_ATOMICS', true],
> --
> 2.8.1
>

Re: [dpdk-dev] [PATCH 1/2] config/arm: add non-SVE march for soc kunpeng930

[Honnappa Nagarahalli]

<snip>

> 
> On Wed, May 12, 2021 at 2:01 PM Chengwen Feng
> <fengchengwen@huawei.com> wrote:
> >
> > Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> > but some compiler doesn't recognize the march because it doesn't
> > support sve.
> 
> Agree with the problem statement.
> 
> + @Juraj Linkeš
> 
> >
> > This patch adds '-march=armv8.2-a+crypto' before
> > '-march=armv8.2-a+crypto+sve' so that:
> > 1. If compiler doesn't support '-march=armv8.2-a+crypto+sve', then it
> > will fallback supports 'armv8.2-a+crypto'.
> > 2. If compiler supports '-march=armv8.2-a+crypto+sve', then it will
> > compile SVE-related code.
> >
> > Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > ---
> >  config/arm/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 3f34ec9..fe6c29b 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -158,7 +158,7 @@ implementer_hisilicon = {
> >              ]
> >          },
> >          '0xd02': {
> > -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> > +            'machine_args': ['-march=armv8.2-a+crypto',
> > + '-march=armv8.2-a+crypto+sve'],
> 
> I think, this problem not specific to Kunpeng. I think, in order to have a generic
> solution, I think, we need to express something like [[armv8.2-a], [crypto],
> [sve]] or so in the code and any infra code can generate a working
> combination to avoid duplicating the combination manually in code and have
> some generic solution for all the platforms.
I think this approach will be too generic. We have to start with v8.0 (as the compiler might not support v8.2-a) and list every feature and check if all those features are supported in the compiler. It might be required that some features might not perform well in certain applications which requires for disabling the features.

I think tweaks like this should be left to the end user.

> 
> i.e
> patch 1: Enable the infrastructure for auto probe based on compiler support.
> patch 2: Fix existing machines including the Kunpeng.
> 
> 
> >              'flags': [
> >                  ['RTE_MACHINE', '"Kunpeng 930"'],
> >                  ['RTE_ARM_FEATURE_ATOMICS', true],
> > --
> > 2.8.1
> >

Re: [dpdk-dev] [PATCH 1/2] config/arm: add non-SVE march for soc kunpeng930

[fengchengwen]

On 2021/5/13 7:00, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>> On Wed, May 12, 2021 at 2:01 PM Chengwen Feng
>> <fengchengwen@huawei.com> wrote:
>>>
>>> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
>>> but some compiler doesn't recognize the march because it doesn't
>>> support sve.
>>
>> Agree with the problem statement.
>>
>> + @Juraj Linkeš
>>
>>>
>>> This patch adds '-march=armv8.2-a+crypto' before
>>> '-march=armv8.2-a+crypto+sve' so that:
>>> 1. If compiler doesn't support '-march=armv8.2-a+crypto+sve', then it
>>> will fallback supports 'armv8.2-a+crypto'.
>>> 2. If compiler supports '-march=armv8.2-a+crypto+sve', then it will
>>> compile SVE-related code.
>>>
>>> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> ---
>>>  config/arm/meson.build | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
>>> 3f34ec9..fe6c29b 100644
>>> --- a/config/arm/meson.build
>>> +++ b/config/arm/meson.build
>>> @@ -158,7 +158,7 @@ implementer_hisilicon = {
>>>              ]
>>>          },
>>>          '0xd02': {
>>> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
>>> +            'machine_args': ['-march=armv8.2-a+crypto',
>>> + '-march=armv8.2-a+crypto+sve'],
>>
>> I think, this problem not specific to Kunpeng. I think, in order to have a generic
>> solution, I think, we need to express something like [[armv8.2-a], [crypto],
>> [sve]] or so in the code and any infra code can generate a working
>> combination to avoid duplicating the combination manually in code and have
>> some generic solution for all the platforms.
> I think this approach will be too generic. We have to start with v8.0 (as the compiler might not support v8.2-a) and list every feature and check if all those features are supported in the compiler. It might be required that some features might not perform well in certain applications which requires for disabling the features.
> 
> I think tweaks like this should be left to the end user.
> 

Agree

Fixed in v2 (separate -march='armv8.2-a+crypto+sve' to two tuples, namely: march_base and march_feature), thanks

>>
>> i.e
>> patch 1: Enable the infrastructure for auto probe based on compiler support.
>> patch 2: Fix existing machines including the Kunpeng.
>>
>>
>>>              'flags': [
>>>                  ['RTE_MACHINE', '"Kunpeng 930"'],
>>>                  ['RTE_ARM_FEATURE_ATOMICS', true],
>>> --
>>> 2.8.1
>>>

[dpdk-dev] [PATCH 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..8563d70 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,20 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+        cflags += ['-DCC_SVE_SUPPORT']
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve')
+        cflags += ['-DCC_SVE_SUPPORT']
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

Re: [dpdk-dev] [PATCH 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>

> 
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 13 +++++++++++++
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c index
> 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build index
> 53c7df7..8563d70 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,20 @@ deps += ['hash']
> 
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +        cflags += ['-DCC_SVE_SUPPORT']
Why is the CC_SVE_SUPPORT flag needed? The compiler has __ARM_FEATURE_SVE flag already which gets defined when '+sve" is added to '-march'.

>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve')
I think this check and the above check do the same thing. i.e. both of them check if +sve flag is passed to the compiler.

> +        cflags += ['-DCC_SVE_SUPPORT']
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> --
> 2.8.1

Re: [dpdk-dev] [PATCH 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>

> 
> >
> > Currently, the SVE code is compiled only when -march supports SVE
> > (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
> approach.
> >
> > The solution:
> > a. If the minimum instruction set support SVE then compiles it.
> > b. Else if the compiler support SVE then compiles it.
> > c. Otherwise don't compile it.
> >
> > [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >
> > Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> > Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > ---
> >  drivers/net/hns3/hns3_rxtx.c |  2 +-
> >  drivers/net/hns3/meson.build | 13 +++++++++++++
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/hns3/hns3_rxtx.c
> > b/drivers/net/hns3/hns3_rxtx.c index
> > 1d7a769..4ef20c6 100644
> > --- a/drivers/net/hns3/hns3_rxtx.c
> > +++ b/drivers/net/hns3/hns3_rxtx.c
> > @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >  static bool
> >  hns3_get_sve_support(void)
> >  {
> > -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> > +#if defined(CC_SVE_SUPPORT)
> >  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >  		return false;
> >  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> > diff --git a/drivers/net/hns3/meson.build
> > b/drivers/net/hns3/meson.build index
> > 53c7df7..8563d70 100644
> > --- a/drivers/net/hns3/meson.build
> > +++ b/drivers/net/hns3/meson.build
> > @@ -35,7 +35,20 @@ deps += ['hash']
> >
> >  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >      sources += files('hns3_rxtx_vec.c')
> > +
> > +    # compile SVE when:
> > +    # a. support SVE in minimum instruction set baseline
> > +    # b. it's not minimum instruction set, but compiler support
> >      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> > +        cflags += ['-DCC_SVE_SUPPORT']
> Why is the CC_SVE_SUPPORT flag needed? The compiler has
> __ARM_FEATURE_SVE flag already which gets defined when '+sve" is added to
> '-march'.
> 
> >          sources += files('hns3_rxtx_vec_sve.c')
> > +    elif cc.has_argument('-march=armv8.2-a+sve')
> I think this check and the above check do the same thing. i.e. both of them
> check if +sve flag is passed to the compiler.
> 
> > +        cflags += ['-DCC_SVE_SUPPORT']
> > +        hns3_sve_lib = static_library('hns3_sve_lib',
> > +                        'hns3_rxtx_vec_sve.c',
> > +                        dependencies: [static_rte_ethdev],
> > +                        include_directories: includes,
> > +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> > +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
I do not understand the need of this block of code, appreciate if you could explain why this is required.

> >      endif
> >  endif
> > --
> > 2.8.1

Re: [dpdk-dev] [PATCH 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/13 7:21, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>>>
>>> Currently, the SVE code is compiled only when -march supports SVE
>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
>> approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> ---
>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>>  drivers/net/hns3/meson.build | 13 +++++++++++++
>>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>> b/drivers/net/hns3/hns3_rxtx.c index
>>> 1d7a769..4ef20c6 100644
>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>  static bool
>>>  hns3_get_sve_support(void)
>>>  {
>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>> +#if defined(CC_SVE_SUPPORT)
>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>  		return false;
>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>> diff --git a/drivers/net/hns3/meson.build
>>> b/drivers/net/hns3/meson.build index
>>> 53c7df7..8563d70 100644
>>> --- a/drivers/net/hns3/meson.build
>>> +++ b/drivers/net/hns3/meson.build
>>> @@ -35,7 +35,20 @@ deps += ['hash']
>>>
>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>      sources += files('hns3_rxtx_vec.c')
>>> +
>>> +    # compile SVE when:
>>> +    # a. support SVE in minimum instruction set baseline
>>> +    # b. it's not minimum instruction set, but compiler support
>>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>> +        cflags += ['-DCC_SVE_SUPPORT']
>> Why is the CC_SVE_SUPPORT flag needed? The compiler has
>> __ARM_FEATURE_SVE flag already which gets defined when '+sve" is added to
>> '-march'.
>>

The CC_SVE_SUPPORT is used to implement the hns3_get_sve_support API (below),
this API located in another file which is hns3_rxtx.c, and this file was
compiled with default machine_args.

	static bool
	hns3_get_sve_support(void)
	{
	#if defined(CC_SVE_SUPPORT)
		if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
			return false;
		if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
			return true;
	#endif
		return false;
	}

If the machine_args doesn't support SVE but compiler support, we will compile
SVE code too, so in this case we need define CC_SVE_SUPPORT, so that in runtime
we could try judge whether support SVE. In this case, __ARM_FEATURE_SVE was not
defined because it is in hns3_rxtx.c which use default machine_args.

If the machine_args supports SVE we sure compile SVE code, in this case, to
maintain consistency, we also define this macro.

>>>          sources += files('hns3_rxtx_vec_sve.c')
>>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>> I think this check and the above check do the same thing. i.e. both of them
>> check if +sve flag is passed to the compiler.
>>

Yes it is.

>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>> +                        'hns3_rxtx_vec_sve.c',
>>> +                        dependencies: [static_rte_ethdev],
>>> +                        include_directories: includes,
>>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> I do not understand the need of this block of code, appreciate if you could explain why this is required.
> 

This is typical usage for compiling some soure file with custom flags (here is '-march=armv8.2-a+sve')
Please ref [1] with keyword 'extract_objects'

[1] https://mesonbuild.com/Reference-manual.html

>>>      endif
>>>  endif
>>> --
>>> 2.8.1
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>

> >>> Currently, the SVE code is compiled only when -march supports SVE
> >>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
> >> approach.
> >>>
> >>> The solution:
> >>> a. If the minimum instruction set support SVE then compiles it.
> >>> b. Else if the compiler support SVE then compiles it.
> >>> c. Otherwise don't compile it.
> >>>
> >>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>>
> >>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >>> Cc: stable@dpdk.org
> >>>
> >>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>> ---
> >>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
> >>> | 13 +++++++++++++
> >>>  2 files changed, 14 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >>> b/drivers/net/hns3/hns3_rxtx.c index
> >>> 1d7a769..4ef20c6 100644
> >>> --- a/drivers/net/hns3/hns3_rxtx.c
> >>> +++ b/drivers/net/hns3/hns3_rxtx.c
> >>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >>>  static bool
> >>>  hns3_get_sve_support(void)
> >>>  {
> >>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >>> +#if defined(CC_SVE_SUPPORT)
> >>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >>>  		return false;
> >>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >>> diff --git a/drivers/net/hns3/meson.build
> >>> b/drivers/net/hns3/meson.build index
> >>> 53c7df7..8563d70 100644
> >>> --- a/drivers/net/hns3/meson.build
> >>> +++ b/drivers/net/hns3/meson.build
> >>> @@ -35,7 +35,20 @@ deps += ['hash']
> >>>
> >>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >>>      sources += files('hns3_rxtx_vec.c')
> >>> +
> >>> +    # compile SVE when:
> >>> +    # a. support SVE in minimum instruction set baseline
> >>> +    # b. it's not minimum instruction set, but compiler support
> >>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >>> +        cflags += ['-DCC_SVE_SUPPORT']
> >> Why is the CC_SVE_SUPPORT flag needed? The compiler has
> >> __ARM_FEATURE_SVE flag already which gets defined when '+sve" is
> >> added to '-march'.
> >>
> 
> The CC_SVE_SUPPORT is used to implement the hns3_get_sve_support API
> (below), this API located in another file which is hns3_rxtx.c, and this file was
> compiled with default machine_args.
> 
> 	static bool
> 	hns3_get_sve_support(void)
> 	{
> 	#if defined(CC_SVE_SUPPORT)
> 		if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> 			return false;
> 		if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> 			return true;
> 	#endif
> 		return false;
> 	}
> 
> If the machine_args doesn't support SVE but compiler support, we will
> compile SVE code too, so in this case we need define CC_SVE_SUPPORT, so
> that in runtime we could try judge whether support SVE. In this case,
> __ARM_FEATURE_SVE was not defined because it is in hns3_rxtx.c which use
> default machine_args.
> 
> If the machine_args supports SVE we sure compile SVE code, in this case, to
> maintain consistency, we also define this macro.
> 
> >>>          sources += files('hns3_rxtx_vec_sve.c')
> >>> +    elif cc.has_argument('-march=armv8.2-a+sve')
> >> I think this check and the above check do the same thing. i.e. both
> >> of them check if +sve flag is passed to the compiler.
> >>
> 
> Yes it is.
> 
> >>> +        cflags += ['-DCC_SVE_SUPPORT']
> >>> +        hns3_sve_lib = static_library('hns3_sve_lib',
> >>> +                        'hns3_rxtx_vec_sve.c',
> >>> +                        dependencies: [static_rte_ethdev],
> >>> +                        include_directories: includes,
> >>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> >>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> > I do not understand the need of this block of code, appreciate if you could
> explain why this is required.
> >
> 
> This is typical usage for compiling some soure file with custom flags (here is '-
> march=armv8.2-a+sve') Please ref [1] with keyword 'extract_objects'
> 
> [1] https://mesonbuild.com/Reference-manual.html
Ack, understand this now, thanks for your patience

> 
> >>>      endif
> >>>  endif
> >>> --
> >>> 2.8.1
> >
> >
> > .
> >

Re: [dpdk-dev] [PATCH 2/2] net/hns3: refactor SVE code compile method

[Bruce Richardson]

On Wed, May 12, 2021 at 11:12:36PM +0000, Honnappa Nagarahalli wrote:
> <snip>
> 
> > 
> > Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> > march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> > 
> > The solution:
> > a. If the minimum instruction set support SVE then compiles it.
> > b. Else if the compiler support SVE then compiles it.
> > c. Otherwise don't compile it.
> > 
> > [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> > 
> > Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> > Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> > Cc: stable@dpdk.org
> > 
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > ---
> >  drivers/net/hns3/hns3_rxtx.c |  2 +-
> >  drivers/net/hns3/meson.build | 13 +++++++++++++
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c index
> > 1d7a769..4ef20c6 100644
> > --- a/drivers/net/hns3/hns3_rxtx.c
> > +++ b/drivers/net/hns3/hns3_rxtx.c
> > @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >  static bool
> >  hns3_get_sve_support(void)
> >  {
> > -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> > +#if defined(CC_SVE_SUPPORT)
> >  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >  		return false;
> >  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> > diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build index
> > 53c7df7..8563d70 100644
> > --- a/drivers/net/hns3/meson.build
> > +++ b/drivers/net/hns3/meson.build
> > @@ -35,7 +35,20 @@ deps += ['hash']
> > 
> >  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >      sources += files('hns3_rxtx_vec.c')
> > +
> > +    # compile SVE when:
> > +    # a. support SVE in minimum instruction set baseline
> > +    # b. it's not minimum instruction set, but compiler support
> >      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> > +        cflags += ['-DCC_SVE_SUPPORT']
> Why is the CC_SVE_SUPPORT flag needed? The compiler has __ARM_FEATURE_SVE flag already which gets defined when '+sve" is added to '-march'.
> 
> >          sources += files('hns3_rxtx_vec_sve.c')
> > +    elif cc.has_argument('-march=armv8.2-a+sve')
> I think this check and the above check do the same thing. i.e. both of them check if +sve flag is passed to the compiler.
>

This is similar to what we do for AVX on x86. The first check is indeed
checking that +sve is passed to the compiler, but the second is different,
and checks whether it is possible for the flag to be passed to the
compiler. This second info then allows a separate C file to be compiled for
that extra instruction set, and then have the functions in it run-time
selected.

/Bruce 

[dpdk-dev] [PATCH v2 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v2: 
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select best -march parameter for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 28 +++++++++++++++++++++++++---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 3 files changed, 39 insertions(+), 4 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v2 1/2] config/arm: select best -march parameter for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature' : ['crypto', 'sve']
3. Select the best march+feature combination based on 'march_base'
and 'march_feature' tuples.
4. Use the best march+feature combination as the default machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..5b91fe1 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -149,7 +149,9 @@ implementer_hisilicon = {
     ],
     'part_number_config': {
         '0xd01': {
-            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
+            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
+            'march_feature' : ['crypto'],
+            'machine_args': ['-mtune=tsv110'],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 920"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -158,7 +160,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
+            'march_feature' : ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +453,26 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the best march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        foreach arch: part_number_config['march_base']
+            if cc.has_argument(arch)
+                machine_march = arch # Set the higher supported arch as possible 
+            endif
+        endforeach
+    endif
+    if part_number_config.has_key('march_feature')
+        foreach feature: part_number_config['march_feature']
+            tmp_machine_march = machine_march + '+' + feature
+            if cc.has_argument(tmp_machine_march)
+                machine_march = tmp_machine_march # Set the morer supported feature as possible
+            endif
+        endforeach
+    endif
+
     # apply supported machine args
-    machine_args = [] # Clear previous machine args
+    machine_args = machine_march
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

[dpdk-dev] [PATCH v2 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..8563d70 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,20 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+        cflags += ['-DCC_SVE_SUPPORT']
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve')
+        cflags += ['-DCC_SVE_SUPPORT']
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

[dpdk-dev] [PATCH v3 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v3:
* fix checkpatch error of 1/2 patch
* modify comments of 1/2 patch
v2:
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select most suitable -march for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 28 +++++++++++++++++++++++++---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 3 files changed, 39 insertions(+), 4 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v3 1/2] config/arm: select most suitable -march for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature' : ['crypto', 'sve']
3. Select the most suitable march+feature combination based on
'march_base' and 'march_feature' tuples.
4. Use the selected march+feature combination as the default
machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..7d1a823 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -149,7 +149,9 @@ implementer_hisilicon = {
     ],
     'part_number_config': {
         '0xd01': {
-            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
+            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
+            'march_feature' : ['crypto'],
+            'machine_args': ['-mtune=tsv110'],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 920"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -158,7 +160,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
+            'march_feature' : ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +453,26 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the most suitable march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        foreach arch: part_number_config['march_base']
+            if cc.has_argument(arch)
+                machine_march = arch # Set the higher supported arch as possible
+            endif
+        endforeach
+    endif
+    if part_number_config.has_key('march_feature')
+        foreach feature: part_number_config['march_feature']
+            tmp_machine_march = machine_march + '+' + feature
+            if cc.has_argument(tmp_machine_march)
+                machine_march = tmp_machine_march # Set the more supported feature as possible
+            endif
+        endforeach
+    endif
+
     # apply supported machine args
-    machine_args = [] # Clear previous machine args
+    machine_args = machine_march
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

[dpdk-dev] [PATCH v3 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..8563d70 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,20 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+        cflags += ['-DCC_SVE_SUPPORT']
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve')
+        cflags += ['-DCC_SVE_SUPPORT']
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

[dpdk-dev] [PATCH v4 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v4:
* fix compile option combine problem
v3:
* fix checkpatch error of 1/2 patch
* modify comments of 1/2 patch
v2:
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select most suitable -march for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 27 +++++++++++++++++++++++++--
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 3 files changed, 39 insertions(+), 3 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature' : ['crypto', 'sve']
3. Select the most suitable march+feature combination based on
'march_base' and 'march_feature' tuples.
4. Use the selected march+feature combination as the default
machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..8551a80 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -149,7 +149,9 @@ implementer_hisilicon = {
     ],
     'part_number_config': {
         '0xd01': {
-            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
+            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
+            'march_feature' : ['crypto'],
+            'machine_args': ['-mtune=tsv110'],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 920"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -158,7 +160,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
+            'march_feature' : ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +453,27 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the most suitable march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        foreach arch: part_number_config['march_base']
+            if cc.has_argument(arch)
+                machine_march = arch # Set the higher supported arch as possible
+            endif
+        endforeach
+    endif
+    if part_number_config.has_key('march_feature')
+        foreach feature: part_number_config['march_feature']
+            tmp_machine_march = machine_march + '+' + feature
+            if cc.has_argument(tmp_machine_march)
+                machine_march = tmp_machine_march # Set the more supported feature as possible
+            endif
+        endforeach
+    endif
+
     # apply supported machine args
     machine_args = [] # Clear previous machine args
+    machine_args += machine_march
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

Re: [dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc

[Jerin Jacob]

On Thu, May 13, 2021 at 6:41 PM Chengwen Feng <fengchengwen@huawei.com> wrote:
>
> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> but some compiler doesn't recognize the march because it doesn't
> support sve.
>
> To solve this bug we use the following scheme:
> 1. Define 'march_base' tuple which defines support march, it should
> arrange from lower to higher.
> e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a']
> 2. Define 'march_feature' tuple which defines support feature.
> e.g. 'march_feature' : ['crypto', 'sve']
> 3. Select the most suitable march+feature combination based on
> 'march_base' and 'march_feature' tuples.
> 4. Use the selected march+feature combination as the default
> machine_args.
>
> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  config/arm/meson.build | 27 +++++++++++++++++++++++++--
>  1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 3f34ec9..8551a80 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -149,7 +149,9 @@ implementer_hisilicon = {
>      ],
>      'part_number_config': {
>          '0xd01': {
> -            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],

Another target has the same issue. Could you fix that all together as
it is generic problem in the existing infrastructure.


> +            'march_feature' : ['crypto'],
> +            'machine_args': ['-mtune=tsv110'],
>              'flags': [
>                  ['RTE_MACHINE', '"Kunpeng 920"'],
>                  ['RTE_ARM_FEATURE_ATOMICS', true],
> @@ -158,7 +160,9 @@ implementer_hisilicon = {
>              ]
>          },
>          '0xd02': {
> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> +            'march_feature' : ['crypto', 'sve'],
> +            'machine_args': [],
>              'flags': [
>                  ['RTE_MACHINE', '"Kunpeng 930"'],
>                  ['RTE_ARM_FEATURE_ATOMICS', true],
> @@ -449,8 +453,27 @@ else
>      # add/overwrite flags in the proper order
>      dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
>
> +    # select the most suitable march+feature combination
> +    machine_march = []
> +    if part_number_config.has_key('march_base')
> +        foreach arch: part_number_config['march_base']
> +            if cc.has_argument(arch)
> +                machine_march = arch # Set the higher supported arch as possible
> +            endif
> +        endforeach
> +    endif
> +    if part_number_config.has_key('march_feature')
> +        foreach feature: part_number_config['march_feature']
> +            tmp_machine_march = machine_march + '+' + feature
> +            if cc.has_argument(tmp_machine_march)
> +                machine_march = tmp_machine_march # Set the more supported feature as possible
> +            endif
> +        endforeach
> +    endif
> +
>      # apply supported machine args
>      machine_args = [] # Clear previous machine args
> +    machine_args += machine_march
>      foreach flag: part_number_config['machine_args']
>          if cc.has_argument(flag)
>              machine_args += flag
> --
> 2.8.1
>

Re: [dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc

[Honnappa Nagarahalli]

<snip>
> 
> On Thu, May 13, 2021 at 6:41 PM Chengwen Feng
> <fengchengwen@huawei.com> wrote:
> >
> > Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> > but some compiler doesn't recognize the march because it doesn't
> > support sve.
> >
> > To solve this bug we use the following scheme:
> > 1. Define 'march_base' tuple which defines support march, it should
> > arrange from lower to higher.
> > e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'] 2. Define
> > 'march_feature' tuple which defines support feature.
> > e.g. 'march_feature' : ['crypto', 'sve'] 3. Select the most suitable
> > march+feature combination based on 'march_base' and 'march_feature'
> > tuples.
> > 4. Use the selected march+feature combination as the default
> > machine_args.
> >
> > Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > ---
> >  config/arm/meson.build | 27 +++++++++++++++++++++++++--
> >  1 file changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 3f34ec9..8551a80 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -149,7 +149,9 @@ implementer_hisilicon = {
> >      ],
> >      'part_number_config': {
> >          '0xd01': {
> > -            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
> > +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
If the compiler supports armv8.1-a, you need to choose armv8.1-a.

> 
> Another target has the same issue. Could you fix that all together as it is
> generic problem in the existing infrastructure.
I think this needs to be more generic solution. IMO, the requirement is as follows:

1) We need to pick the most closest march_base supported by the compiler. For ex: If the SoC support v8.2 and the compiler supports v8.1, we need to pick v8.1
2) SoCs are allowed to support a base march version + hand picked features from the next 1 base marchs. i.e. armv8.x compliant implementation can include any features from armv8.(x + 1). Please refer to  Arm-ARM section A2 for more details. So, it is possible that the compiler supports a base march and a bunch of optional features from the next version. We need to test all the features allowed by the architecture and pick the ones that are supported in the compiler.

> 
> 
> > +            'march_feature' : ['crypto'],
> > +            'machine_args': ['-mtune=tsv110'],
> >              'flags': [
> >                  ['RTE_MACHINE', '"Kunpeng 920"'],
> >                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -158,7 +160,9
> > @@ implementer_hisilicon = {
> >              ]
> >          },
> >          '0xd02': {
> > -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> > +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> > +            'march_feature' : ['crypto', 'sve'],
> > +            'machine_args': [],
> >              'flags': [
> >                  ['RTE_MACHINE', '"Kunpeng 930"'],
> >                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8 +453,27
> > @@ else
> >      # add/overwrite flags in the proper order
> >      dpdk_flags = flags_common + implementer_config['flags'] +
> > part_number_config.get('flags', []) + soc_flags
> >
> > +    # select the most suitable march+feature combination
> > +    machine_march = []
> > +    if part_number_config.has_key('march_base')
> > +        foreach arch: part_number_config['march_base']
> > +            if cc.has_argument(arch)
> > +                machine_march = arch # Set the higher supported arch as
> possible
> > +            endif
> > +        endforeach
> > +    endif
> > +    if part_number_config.has_key('march_feature')
> > +        foreach feature: part_number_config['march_feature']
> > +            tmp_machine_march = machine_march + '+' + feature
> > +            if cc.has_argument(tmp_machine_march)
> > +                machine_march = tmp_machine_march # Set the more supported
> feature as possible
> > +            endif
> > +        endforeach
> > +    endif
> > +
> >      # apply supported machine args
> >      machine_args = [] # Clear previous machine args
> > +    machine_args += machine_march
> >      foreach flag: part_number_config['machine_args']
> >          if cc.has_argument(flag)
> >              machine_args += flag
> > --
> > 2.8.1
> >

Re: [dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc

[fengchengwen]

On 2021/5/14 7:12, Honnappa Nagarahalli wrote:
> <snip>
>>
>> On Thu, May 13, 2021 at 6:41 PM Chengwen Feng
>> <fengchengwen@huawei.com> wrote:
>>>
>>> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
>>> but some compiler doesn't recognize the march because it doesn't
>>> support sve.
>>>
>>> To solve this bug we use the following scheme:
>>> 1. Define 'march_base' tuple which defines support march, it should
>>> arrange from lower to higher.
>>> e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'] 2. Define
>>> 'march_feature' tuple which defines support feature.
>>> e.g. 'march_feature' : ['crypto', 'sve'] 3. Select the most suitable
>>> march+feature combination based on 'march_base' and 'march_feature'
>>> tuples.
>>> 4. Use the selected march+feature combination as the default
>>> machine_args.
>>>
>>> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> ---
>>>  config/arm/meson.build | 27 +++++++++++++++++++++++++--
>>>  1 file changed, 25 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
>>> 3f34ec9..8551a80 100644
>>> --- a/config/arm/meson.build
>>> +++ b/config/arm/meson.build
>>> @@ -149,7 +149,9 @@ implementer_hisilicon = {
>>>      ],
>>>      'part_number_config': {
>>>          '0xd01': {
>>> -            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
>>> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> If the compiler supports armv8.1-a, you need to choose armv8.1-a.
> 
>>
>> Another target has the same issue. Could you fix that all together as it is
>> generic problem in the existing infrastructure.
> I think this needs to be more generic solution. IMO, the requirement is as follows:
> 
> 1) We need to pick the most closest march_base supported by the compiler. For ex: If the SoC support v8.2 and the compiler supports v8.1, we need to pick v8.1
> 2) SoCs are allowed to support a base march version + hand picked features from the next 1 base marchs. i.e. armv8.x compliant implementation can include any features from armv8.(x + 1). Please refer to  Arm-ARM section A2 for more details. So, it is possible that the compiler supports a base march and a bunch of optional features from the next version. We need to test all the features allowed by the architecture and pick the ones that are supported in the compiler.
> 

I try to add 'march_base' : ['-march=armv8-a', '-march=armv8.5-a'] to cn10k, and then find it
can't work with ['RTE_ARM_FEATURE_ATOMICS', true] when using gcc7.2:
	[268/2250] Compiling C object lib/librte_stack.a.p/stack_rte_stack_lf.c.o
	FAILED: lib/librte_stack.a.p/stack_rte_stack_lf.c.o
	...
	{standard input}: Assembler messages:
	{standard input}:13: Error: selected processor does not support `caspl x0,x1,x2,x3,[x5]'
	[347/2250] Compiling C object lib/librte_hash.a.p/hash_rte_cuckoo_hash.c.o
	ninja: build stopped: subcommand failed.
	make: *** [cn10k] Error 1
It seem can't simplely add '-march=armv8-a' in 'march_base'.
And it require a lot of testing to get the right 'march_base' and 'march_feature' parameters.
So for v5, I just modify the kunpeng930's config which was well tested.

I think the 'march_base' and 'march_feature' could well solve the gcc's minor-version problem.
Note: the minor-version means a few version which are closes, not big gap, like gcc5.4 and gcc10.2

For that old gcc which could not support the 'march' that defined in 'machine_args' or 'march_base'
I think it better use the 'generic' profile else it will compile fail which showed above.

So how about add new tuple: fallback_generic? eg:
	'0xd02': {
            'march_base': ['-march=armv8.2-a'],
            'march_feature': ['crypto', 'sve'],
            'machine_args': [],
            'flags': [
                ['RTE_MACHINE', '"Kunpeng 930"'],
                ['RTE_ARM_FEATURE_ATOMICS', true],
                ['RTE_MAX_LCORE', 1280],
                ['RTE_MAX_NUMA_NODES', 16]
            ],
	    'fallback_generic': true
        }
PS: The premise is that the 'generic' profile is tested.


>>
>>
>>> +            'march_feature' : ['crypto'],
>>> +            'machine_args': ['-mtune=tsv110'],
>>>              'flags': [
>>>                  ['RTE_MACHINE', '"Kunpeng 920"'],
>>>                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -158,7 +160,9
>>> @@ implementer_hisilicon = {
>>>              ]
>>>          },
>>>          '0xd02': {
>>> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
>>> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
>>> +            'march_feature' : ['crypto', 'sve'],
>>> +            'machine_args': [],
>>>              'flags': [
>>>                  ['RTE_MACHINE', '"Kunpeng 930"'],
>>>                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8 +453,27
>>> @@ else
>>>      # add/overwrite flags in the proper order
>>>      dpdk_flags = flags_common + implementer_config['flags'] +
>>> part_number_config.get('flags', []) + soc_flags
>>>
>>> +    # select the most suitable march+feature combination
>>> +    machine_march = []
>>> +    if part_number_config.has_key('march_base')
>>> +        foreach arch: part_number_config['march_base']
>>> +            if cc.has_argument(arch)
>>> +                machine_march = arch # Set the higher supported arch as
>> possible
>>> +            endif
>>> +        endforeach
>>> +    endif
>>> +    if part_number_config.has_key('march_feature')
>>> +        foreach feature: part_number_config['march_feature']
>>> +            tmp_machine_march = machine_march + '+' + feature
>>> +            if cc.has_argument(tmp_machine_march)
>>> +                machine_march = tmp_machine_march # Set the more supported
>> feature as possible
>>> +            endif
>>> +        endforeach
>>> +    endif
>>> +
>>>      # apply supported machine args
>>>      machine_args = [] # Clear previous machine args
>>> +    machine_args += machine_march
>>>      foreach flag: part_number_config['machine_args']
>>>          if cc.has_argument(flag)
>>>              machine_args += flag
>>> --
>>> 2.8.1
>>>

Re: [dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc

[Honnappa Nagarahalli]

<snip>

> >>
> >> On Thu, May 13, 2021 at 6:41 PM Chengwen Feng
> >> <fengchengwen@huawei.com> wrote:
> >>>
> >>> Currently, the soc_kunpeng930 declares
> >>> '-march=armv8.2-a+crypto+sve', but some compiler doesn't recognize
> >>> the march because it doesn't support sve.
> >>>
> >>> To solve this bug we use the following scheme:
> >>> 1. Define 'march_base' tuple which defines support march, it should
> >>> arrange from lower to higher.
> >>> e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'] 2. Define
> >>> 'march_feature' tuple which defines support feature.
> >>> e.g. 'march_feature' : ['crypto', 'sve'] 3. Select the most suitable
> >>> march+feature combination based on 'march_base' and 'march_feature'
> >>> tuples.
> >>> 4. Use the selected march+feature combination as the default
> >>> machine_args.
> >>>
> >>> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> >>>
> >>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>> ---
> >>>  config/arm/meson.build | 27 +++++++++++++++++++++++++--
> >>>  1 file changed, 25 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> >>> 3f34ec9..8551a80 100644
> >>> --- a/config/arm/meson.build
> >>> +++ b/config/arm/meson.build
> >>> @@ -149,7 +149,9 @@ implementer_hisilicon = {
> >>>      ],
> >>>      'part_number_config': {
> >>>          '0xd01': {
> >>> -            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
> >>> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> > If the compiler supports armv8.1-a, you need to choose armv8.1-a.
> >
> >>
> >> Another target has the same issue. Could you fix that all together as
> >> it is generic problem in the existing infrastructure.
> > I think this needs to be more generic solution. IMO, the requirement is as
> follows:
> >
> > 1) We need to pick the most closest march_base supported by the
> > compiler. For ex: If the SoC support v8.2 and the compiler supports
> > v8.1, we need to pick v8.1
> > 2) SoCs are allowed to support a base march version + hand picked features
> from the next 1 base marchs. i.e. armv8.x compliant implementation can
> include any features from armv8.(x + 1). Please refer to  Arm-ARM section A2
> for more details. So, it is possible that the compiler supports a base march
> and a bunch of optional features from the next version. We need to test all
> the features allowed by the architecture and pick the ones that are supported
> in the compiler.
> >
> 
> I try to add 'march_base' : ['-march=armv8-a', '-march=armv8.5-a'] to cn10k,
> and then find it can't work with ['RTE_ARM_FEATURE_ATOMICS', true] when
> using gcc7.2:
> 	[268/2250] Compiling C object
> lib/librte_stack.a.p/stack_rte_stack_lf.c.o
> 	FAILED: lib/librte_stack.a.p/stack_rte_stack_lf.c.o
> 	...
> 	{standard input}: Assembler messages:
> 	{standard input}:13: Error: selected processor does not support `caspl
> x0,x1,x2,x3,[x5]'
> 	[347/2250] Compiling C object
> lib/librte_hash.a.p/hash_rte_cuckoo_hash.c.o
> 	ninja: build stopped: subcommand failed.
> 	make: *** [cn10k] Error 1
> It seem can't simplely add '-march=armv8-a' in 'march_base'.
> And it require a lot of testing to get the right 'march_base' and
> 'march_feature' parameters.
> So for v5, I just modify the kunpeng930's config which was well tested.
> 
> I think the 'march_base' and 'march_feature' could well solve the gcc's minor-
> version problem.
> Note: the minor-version means a few version which are closes, not big gap,
> like gcc5.4 and gcc10.2
> 
> For that old gcc which could not support the 'march' that defined in
> 'machine_args' or 'march_base'
> I think it better use the 'generic' profile else it will compile fail which showed
> above.
> 
> So how about add new tuple: fallback_generic? eg:
> 	'0xd02': {
>             'march_base': ['-march=armv8.2-a'],
>             'march_feature': ['crypto', 'sve'],
>             'machine_args': [],
>             'flags': [
>                 ['RTE_MACHINE', '"Kunpeng 930"'],
>                 ['RTE_ARM_FEATURE_ATOMICS', true],
>                 ['RTE_MAX_LCORE', 1280],
>                 ['RTE_MAX_NUMA_NODES', 16]
>             ],
> 	    'fallback_generic': true
>         }
> PS: The premise is that the 'generic' profile is tested.
Jerin, how big of a problem is this (i.e. having to compile the code with an older version of the compiler)? Is it just one old version of the compiler or there are several of them? Do they all need to be captured in the meson.build file? I am just trying to understand the need for a generic approach.

> 
> 
> >>
> >>
> >>> +            'march_feature' : ['crypto'],
> >>> +            'machine_args': ['-mtune=tsv110'],
> >>>              'flags': [
> >>>                  ['RTE_MACHINE', '"Kunpeng 920"'],
> >>>                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -158,7 +160,9
> >>> @@ implementer_hisilicon = {
> >>>              ]
> >>>          },
> >>>          '0xd02': {
> >>> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> >>> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> >>> +            'march_feature' : ['crypto', 'sve'],
> >>> +            'machine_args': [],
> >>>              'flags': [
> >>>                  ['RTE_MACHINE', '"Kunpeng 930"'],
> >>>                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8
> >>> +453,27 @@ else
> >>>      # add/overwrite flags in the proper order
> >>>      dpdk_flags = flags_common + implementer_config['flags'] +
> >>> part_number_config.get('flags', []) + soc_flags
> >>>
> >>> +    # select the most suitable march+feature combination
> >>> +    machine_march = []
> >>> +    if part_number_config.has_key('march_base')
> >>> +        foreach arch: part_number_config['march_base']
> >>> +            if cc.has_argument(arch)
> >>> +                machine_march = arch # Set the higher supported
> >>> + arch as
> >> possible
> >>> +            endif
> >>> +        endforeach
> >>> +    endif
> >>> +    if part_number_config.has_key('march_feature')
> >>> +        foreach feature: part_number_config['march_feature']
> >>> +            tmp_machine_march = machine_march + '+' + feature
> >>> +            if cc.has_argument(tmp_machine_march)
> >>> +                machine_march = tmp_machine_march # Set the more
> >>> + supported
> >> feature as possible
> >>> +            endif
> >>> +        endforeach
> >>> +    endif
> >>> +
> >>>      # apply supported machine args
> >>>      machine_args = [] # Clear previous machine args
> >>> +    machine_args += machine_march
> >>>      foreach flag: part_number_config['machine_args']
> >>>          if cc.has_argument(flag)
> >>>              machine_args += flag
> >>> --
> >>> 2.8.1
> >>>

Re: [dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc

[Jerin Jacob]

On Tue, May 18, 2021 at 6:55 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
>
> > >>
> > >> On Thu, May 13, 2021 at 6:41 PM Chengwen Feng
> > >> <fengchengwen@huawei.com> wrote:
> > >>>
> > >>> Currently, the soc_kunpeng930 declares
> > >>> '-march=armv8.2-a+crypto+sve', but some compiler doesn't recognize
> > >>> the march because it doesn't support sve.
> > >>>
> > >>> To solve this bug we use the following scheme:
> > >>> 1. Define 'march_base' tuple which defines support march, it should
> > >>> arrange from lower to higher.
> > >>> e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'] 2. Define
> > >>> 'march_feature' tuple which defines support feature.
> > >>> e.g. 'march_feature' : ['crypto', 'sve'] 3. Select the most suitable
> > >>> march+feature combination based on 'march_base' and 'march_feature'
> > >>> tuples.
> > >>> 4. Use the selected march+feature combination as the default
> > >>> machine_args.
> > >>>
> > >>> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> > >>>
> > >>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > >>> ---
> > >>>  config/arm/meson.build | 27 +++++++++++++++++++++++++--
> > >>>  1 file changed, 25 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > >>> 3f34ec9..8551a80 100644
> > >>> --- a/config/arm/meson.build
> > >>> +++ b/config/arm/meson.build
> > >>> @@ -149,7 +149,9 @@ implementer_hisilicon = {
> > >>>      ],
> > >>>      'part_number_config': {
> > >>>          '0xd01': {
> > >>> -            'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'],
> > >>> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> > > If the compiler supports armv8.1-a, you need to choose armv8.1-a.
> > >
> > >>
> > >> Another target has the same issue. Could you fix that all together as
> > >> it is generic problem in the existing infrastructure.
> > > I think this needs to be more generic solution. IMO, the requirement is as
> > follows:
> > >
> > > 1) We need to pick the most closest march_base supported by the
> > > compiler. For ex: If the SoC support v8.2 and the compiler supports
> > > v8.1, we need to pick v8.1
> > > 2) SoCs are allowed to support a base march version + hand picked features
> > from the next 1 base marchs. i.e. armv8.x compliant implementation can
> > include any features from armv8.(x + 1). Please refer to  Arm-ARM section A2
> > for more details. So, it is possible that the compiler supports a base march
> > and a bunch of optional features from the next version. We need to test all
> > the features allowed by the architecture and pick the ones that are supported
> > in the compiler.
> > >
> >
> > I try to add 'march_base' : ['-march=armv8-a', '-march=armv8.5-a'] to cn10k,
> > and then find it can't work with ['RTE_ARM_FEATURE_ATOMICS', true] when
> > using gcc7.2:
> >       [268/2250] Compiling C object
> > lib/librte_stack.a.p/stack_rte_stack_lf.c.o
> >       FAILED: lib/librte_stack.a.p/stack_rte_stack_lf.c.o
> >       ...
> >       {standard input}: Assembler messages:
> >       {standard input}:13: Error: selected processor does not support `caspl
> > x0,x1,x2,x3,[x5]'
> >       [347/2250] Compiling C object
> > lib/librte_hash.a.p/hash_rte_cuckoo_hash.c.o
> >       ninja: build stopped: subcommand failed.
> >       make: *** [cn10k] Error 1
> > It seem can't simplely add '-march=armv8-a' in 'march_base'.
> > And it require a lot of testing to get the right 'march_base' and
> > 'march_feature' parameters.
> > So for v5, I just modify the kunpeng930's config which was well tested.
> >
> > I think the 'march_base' and 'march_feature' could well solve the gcc's minor-
> > version problem.
> > Note: the minor-version means a few version which are closes, not big gap,
> > like gcc5.4 and gcc10.2
> >
> > For that old gcc which could not support the 'march' that defined in
> > 'machine_args' or 'march_base'
> > I think it better use the 'generic' profile else it will compile fail which showed
> > above.
> >
> > So how about add new tuple: fallback_generic? eg:
> >       '0xd02': {
> >             'march_base': ['-march=armv8.2-a'],
> >             'march_feature': ['crypto', 'sve'],
> >             'machine_args': [],
> >             'flags': [
> >                 ['RTE_MACHINE', '"Kunpeng 930"'],
> >                 ['RTE_ARM_FEATURE_ATOMICS', true],
> >                 ['RTE_MAX_LCORE', 1280],
> >                 ['RTE_MAX_NUMA_NODES', 16]
> >             ],
> >           'fallback_generic': true
> >         }
> > PS: The premise is that the 'generic' profile is tested.
> Jerin, how big of a problem is this (i.e. having to compile the code with an older version of the compiler)? Is it just one old version of the compiler or there are several of them? Do they all need to be captured in the meson.build file? I am just trying to understand the need for a generic approach.

IMO, We are supporting from gcc 4.7. So a lot of combinations are possible.


>
> >
> >
> > >>
> > >>
> > >>> +            'march_feature' : ['crypto'],
> > >>> +            'machine_args': ['-mtune=tsv110'],
> > >>>              'flags': [
> > >>>                  ['RTE_MACHINE', '"Kunpeng 920"'],
> > >>>                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -158,7 +160,9
> > >>> @@ implementer_hisilicon = {
> > >>>              ]
> > >>>          },
> > >>>          '0xd02': {
> > >>> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> > >>> +            'march_base' : ['-march=armv8-a', '-march=armv8.2-a'],
> > >>> +            'march_feature' : ['crypto', 'sve'],
> > >>> +            'machine_args': [],
> > >>>              'flags': [
> > >>>                  ['RTE_MACHINE', '"Kunpeng 930"'],
> > >>>                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8
> > >>> +453,27 @@ else
> > >>>      # add/overwrite flags in the proper order
> > >>>      dpdk_flags = flags_common + implementer_config['flags'] +
> > >>> part_number_config.get('flags', []) + soc_flags
> > >>>
> > >>> +    # select the most suitable march+feature combination
> > >>> +    machine_march = []
> > >>> +    if part_number_config.has_key('march_base')
> > >>> +        foreach arch: part_number_config['march_base']
> > >>> +            if cc.has_argument(arch)
> > >>> +                machine_march = arch # Set the higher supported
> > >>> + arch as
> > >> possible
> > >>> +            endif
> > >>> +        endforeach
> > >>> +    endif
> > >>> +    if part_number_config.has_key('march_feature')
> > >>> +        foreach feature: part_number_config['march_feature']
> > >>> +            tmp_machine_march = machine_march + '+' + feature
> > >>> +            if cc.has_argument(tmp_machine_march)
> > >>> +                machine_march = tmp_machine_march # Set the more
> > >>> + supported
> > >> feature as possible
> > >>> +            endif
> > >>> +        endforeach
> > >>> +    endif
> > >>> +
> > >>>      # apply supported machine args
> > >>>      machine_args = [] # Clear previous machine args
> > >>> +    machine_args += machine_march
> > >>>      foreach flag: part_number_config['machine_args']
> > >>>          if cc.has_argument(flag)
> > >>>              machine_args += flag
> > >>> --
> > >>> 2.8.1
> > >>>
>

[dpdk-dev] [PATCH v4 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..8563d70 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,20 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+        cflags += ['-DCC_SVE_SUPPORT']
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve')
+        cflags += ['-DCC_SVE_SUPPORT']
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

Re: [dpdk-dev] [PATCH v4 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>

> 
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 13 +++++++++++++
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..8563d70 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,20 @@ deps += ['hash']
> 
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +        cflags += ['-DCC_SVE_SUPPORT']
Can you please look at commit 21c4f1c7b2f8e637ecff9b9180e21f6b4505715f? This commit removed the CC_SVE_SUPPORT flag due to a compilation error.

>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve')
> +        cflags += ['-DCC_SVE_SUPPORT']
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> --
> 2.8.1

Re: [dpdk-dev] [PATCH v4 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/14 6:19, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>  drivers/net/hns3/meson.build | 13 +++++++++++++
>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>> index 1d7a769..4ef20c6 100644
>> --- a/drivers/net/hns3/hns3_rxtx.c
>> +++ b/drivers/net/hns3/hns3_rxtx.c
>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>  static bool
>>  hns3_get_sve_support(void)
>>  {
>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>> +#if defined(CC_SVE_SUPPORT)
>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>  		return false;
>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>> index 53c7df7..8563d70 100644
>> --- a/drivers/net/hns3/meson.build
>> +++ b/drivers/net/hns3/meson.build
>> @@ -35,7 +35,20 @@ deps += ['hash']
>>
>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>      sources += files('hns3_rxtx_vec.c')
>> +
>> +    # compile SVE when:
>> +    # a. support SVE in minimum instruction set baseline
>> +    # b. it's not minimum instruction set, but compiler support
>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>> +        cflags += ['-DCC_SVE_SUPPORT']
> Can you please look at commit 21c4f1c7b2f8e637ecff9b9180e21f6b4505715f? This commit removed the CC_SVE_SUPPORT flag due to a compilation error.
> 

The original is cflags = ['-DCC_SVE_SUPPORT'] which will rewrite cflags
And here we use symbol '+=', it only add extra macro which is CC_SVE_SUPPORT
So it's ok.

>>          sources += files('hns3_rxtx_vec_sve.c')
>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>> +        cflags += ['-DCC_SVE_SUPPORT']
>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>> +                        'hns3_rxtx_vec_sve.c',
>> +                        dependencies: [static_rte_ethdev],
>> +                        include_directories: includes,
>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>      endif
>>  endif
>> --
>> 2.8.1
> 
> 
> .
> 

[dpdk-dev] [PATCH v5 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v5:
* make sure 'march_feature' parsed depend on 'march_base'
* only the kunpeng930 use the new option
v4:
* fix compile option combine problem of 1/2 patch
v3:
* fix checkpatch error of 1/2 patch
* modify comments of 1/2 patch
v2:
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select most suitable -march for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 31 +++++++++++++++++++++++++++++--
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 3 files changed, 43 insertions(+), 3 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v5 1/2] config/arm: select most suitable -march for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature': ['crypto', 'sve']
Note: If user defined 'march_feature', it also needs to define a valid
'march_base' because 'march_feature' depends on 'march_base' when
checking validity.
3. Select the most suitable march+feature combination based on
'march_base' and 'march_feature' tuples.
4. Use the selected march+feature combination as the default
machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..044812f 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -158,7 +158,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base': ['-march=armv8.2-a'],
+            'march_feature': ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +451,33 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the most suitable march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        tmp_machine_march = ''
+        march_valid = false
+        foreach march: part_number_config['march_base']
+            if cc.has_argument(march)
+                tmp_machine_march = march # Set the higher supported march as possible
+                march_valid = true
+            endif
+        endforeach
+        # select feature only when march valid
+        if march_valid and part_number_config.has_key('march_feature')
+            foreach feature: part_number_config['march_feature']
+                tmp_feature = tmp_machine_march + '+' + feature
+                if cc.has_argument(tmp_feature)
+                    tmp_machine_march = tmp_feature # Set the more supported feature as possible
+                endif
+            endforeach
+        endif
+        if march_valid
+            machine_march = [tmp_machine_march]
+        endif
+    endif
+
     # apply supported machine args
-    machine_args = [] # Clear previous machine args
+    machine_args = machine_march # Init with machine march which set above
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

[dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..8563d70 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,20 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+        cflags += ['-DCC_SVE_SUPPORT']
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve')
+        cflags += ['-DCC_SVE_SUPPORT']
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>

> 
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Looks good to me.
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>

> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 13 +++++++++++++
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..8563d70 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,20 @@ deps += ['hash']
> 
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +        cflags += ['-DCC_SVE_SUPPORT']
>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve')
> +        cflags += ['-DCC_SVE_SUPPORT']
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> --
> 2.8.1

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

Hi, Thomas, Ferruh

This patch is part of the hns3 SVE compilation solution and can work independently. Could you review it ?

Best regards

On 2021/5/14 22:12, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Looks good to me.
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> 
>> ---
>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>  drivers/net/hns3/meson.build | 13 +++++++++++++
>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>> index 1d7a769..4ef20c6 100644
>> --- a/drivers/net/hns3/hns3_rxtx.c
>> +++ b/drivers/net/hns3/hns3_rxtx.c
>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>  static bool
>>  hns3_get_sve_support(void)
>>  {
>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>> +#if defined(CC_SVE_SUPPORT)
>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>  		return false;
>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>> index 53c7df7..8563d70 100644
>> --- a/drivers/net/hns3/meson.build
>> +++ b/drivers/net/hns3/meson.build
>> @@ -35,7 +35,20 @@ deps += ['hash']
>>
>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>      sources += files('hns3_rxtx_vec.c')
>> +
>> +    # compile SVE when:
>> +    # a. support SVE in minimum instruction set baseline
>> +    # b. it's not minimum instruction set, but compiler support
>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>> +        cflags += ['-DCC_SVE_SUPPORT']
>>          sources += files('hns3_rxtx_vec_sve.c')
>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>> +        cflags += ['-DCC_SVE_SUPPORT']
>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>> +                        'hns3_rxtx_vec_sve.c',
>> +                        dependencies: [static_rte_ethdev],
>> +                        include_directories: includes,
>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>      endif
>>  endif
>> --
>> 2.8.1
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>
> 
> Hi, Thomas, Ferruh
> 
> This patch is part of the hns3 SVE compilation solution and can work
> independently. Could you review it ?
I believe this patch is targeted for 20.08 release (as 20.05 is already close to completion), is my understanding correct?
If it is targeted for 20.08, it will give us sometime to do few experiments with the generic approach?

> 
> Best regards
> 
> On 2021/5/14 22:12, Honnappa Nagarahalli wrote:
> > <snip>
> >
> >>
> >> Currently, the SVE code is compiled only when -march supports SVE
> >> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
> approach.
> >>
> >> The solution:
> >> a. If the minimum instruction set support SVE then compiles it.
> >> b. Else if the compiler support SVE then compiles it.
> >> c. Otherwise don't compile it.
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>
> >> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > Looks good to me.
> > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> >
> >> ---
> >>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build |
> >> 13 +++++++++++++
> >>  2 files changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> >> --- a/drivers/net/hns3/hns3_rxtx.c
> >> +++ b/drivers/net/hns3/hns3_rxtx.c
> >> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >>  static bool
> >>  hns3_get_sve_support(void)
> >>  {
> >> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >> +#if defined(CC_SVE_SUPPORT)
> >>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >>  		return false;
> >>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >> diff --git a/drivers/net/hns3/meson.build
> >> b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
> >> --- a/drivers/net/hns3/meson.build
> >> +++ b/drivers/net/hns3/meson.build
> >> @@ -35,7 +35,20 @@ deps += ['hash']
> >>
> >>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >>      sources += files('hns3_rxtx_vec.c')
> >> +
> >> +    # compile SVE when:
> >> +    # a. support SVE in minimum instruction set baseline
> >> +    # b. it's not minimum instruction set, but compiler support
> >>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >> +        cflags += ['-DCC_SVE_SUPPORT']
> >>          sources += files('hns3_rxtx_vec_sve.c')
> >> +    elif cc.has_argument('-march=armv8.2-a+sve')
> >> +        cflags += ['-DCC_SVE_SUPPORT']
> >> +        hns3_sve_lib = static_library('hns3_sve_lib',
> >> +                        'hns3_rxtx_vec_sve.c',
> >> +                        dependencies: [static_rte_ethdev],
> >> +                        include_directories: includes,
> >> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> >> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >>      endif
> >>  endif
> >> --
> >> 2.8.1
> >
> >
> > .
> >

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

> <snip>
> >
> > Hi, Thomas, Ferruh
> >
> > This patch is part of the hns3 SVE compilation solution and can work
> > independently. Could you review it ?
> I believe this patch is targeted for 20.08 release (as 20.05 is already close to
> completion), is my understanding correct?
> If it is targeted for 20.08, it will give us sometime to do few experiments with
> the generic approach?
Apologies, please ignore my comments, I misunderstood the patch. I do not have any issues with this patch.

> 
> >
> > Best regards
> >
> > On 2021/5/14 22:12, Honnappa Nagarahalli wrote:
> > > <snip>
> > >
> > >>
> > >> Currently, the SVE code is compiled only when -march supports SVE
> > >> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with
> > >> this
> > approach.
> > >>
> > >> The solution:
> > >> a. If the minimum instruction set support SVE then compiles it.
> > >> b. Else if the compiler support SVE then compiles it.
> > >> c. Otherwise don't compile it.
> > >>
> > >> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> > >>
> > >> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> > >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> > >> Cc: stable@dpdk.org
> > >>
> > >> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > > Looks good to me.
> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > >
> > >> ---
> > >>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
> > >> |
> > >> 13 +++++++++++++
> > >>  2 files changed, 14 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/net/hns3/hns3_rxtx.c
> > >> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> > >> --- a/drivers/net/hns3/hns3_rxtx.c
> > >> +++ b/drivers/net/hns3/hns3_rxtx.c
> > >> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> > >>  static bool
> > >>  hns3_get_sve_support(void)
> > >>  {
> > >> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> > >> +#if defined(CC_SVE_SUPPORT)
> > >>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> > >>  		return false;
> > >>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> > >> diff --git a/drivers/net/hns3/meson.build
> > >> b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
> > >> --- a/drivers/net/hns3/meson.build
> > >> +++ b/drivers/net/hns3/meson.build
> > >> @@ -35,7 +35,20 @@ deps += ['hash']
> > >>
> > >>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> > >>      sources += files('hns3_rxtx_vec.c')
> > >> +
> > >> +    # compile SVE when:
> > >> +    # a. support SVE in minimum instruction set baseline
> > >> +    # b. it's not minimum instruction set, but compiler support
> > >>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> > >> +        cflags += ['-DCC_SVE_SUPPORT']
> > >>          sources += files('hns3_rxtx_vec_sve.c')
> > >> +    elif cc.has_argument('-march=armv8.2-a+sve')
> > >> +        cflags += ['-DCC_SVE_SUPPORT']
> > >> +        hns3_sve_lib = static_library('hns3_sve_lib',
> > >> +                        'hns3_rxtx_vec_sve.c',
> > >> +                        dependencies: [static_rte_ethdev],
> > >> +                        include_directories: includes,
> > >> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> > >> +        objs +=
> > >> + hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> > >>      endif
> > >>  endif
> > >> --
> > >> 2.8.1
> > >
> > >
> > > .
> > >

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/18/2021 1:41 PM, fengchengwen wrote:
> Hi, Thomas, Ferruh
> 
> This patch is part of the hns3 SVE compilation solution and can work independently. Could you review it ?
> 

Hi Chengwen,

This patch has been missed as being part of the config file set. As far as I
understand you want this change for v20.05, let me check it right now as today
is the -rc4 release day.

> Best regards
> 
> On 2021/5/14 22:12, Honnappa Nagarahalli wrote:
>> <snip>
>>
>>>
>>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> Looks good to me.
>> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>>
>>> ---
>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>>  drivers/net/hns3/meson.build | 13 +++++++++++++
>>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>>> index 1d7a769..4ef20c6 100644
>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>  static bool
>>>  hns3_get_sve_support(void)
>>>  {
>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>> +#if defined(CC_SVE_SUPPORT)
>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>  		return false;
>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>>> index 53c7df7..8563d70 100644
>>> --- a/drivers/net/hns3/meson.build
>>> +++ b/drivers/net/hns3/meson.build
>>> @@ -35,7 +35,20 @@ deps += ['hash']
>>>
>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>      sources += files('hns3_rxtx_vec.c')
>>> +
>>> +    # compile SVE when:
>>> +    # a. support SVE in minimum instruction set baseline
>>> +    # b. it's not minimum instruction set, but compiler support
>>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>          sources += files('hns3_rxtx_vec_sve.c')
>>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>> +                        'hns3_rxtx_vec_sve.c',
>>> +                        dependencies: [static_rte_ethdev],
>>> +                        include_directories: includes,
>>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>      endif
>>>  endif
>>> --
>>> 2.8.1
>>
>>
>> .
>>
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/14/2021 3:12 PM, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Looks good to me.
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> 

Applied to dpdk-next-net/main, thanks.

(Only this patch, 2/2, applied, not whole set)

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

Thanks a lot, Ferruh & Honnappa.

On 2021/5/19 0:27, Ferruh Yigit wrote:
> On 5/14/2021 3:12 PM, Honnappa Nagarahalli wrote:
>> <snip>
>>
>>>
>>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> Looks good to me.
>> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>>
> 
> Applied to dpdk-next-net/main, thanks.
> 
> (Only this patch, 2/2, applied, not whole set)
> 
> .
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[David Marchand]

On Tue, May 18, 2021 at 6:28 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 5/14/2021 3:12 PM, Honnappa Nagarahalli wrote:
> > <snip>
> >
> >>
> >> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> >> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> >>
> >> The solution:
> >> a. If the minimum instruction set support SVE then compiles it.
> >> b. Else if the compiler support SVE then compiles it.
> >> c. Otherwise don't compile it.
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>
> >> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > Looks good to me.
> > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> >
>
> Applied to dpdk-next-net/main, thanks.
>
> (Only this patch, 2/2, applied, not whole set)

UNH caught a build regression on next-net and I think this is due to this patch:
https://lab.dpdk.org/results/dashboard/tarballs/15259/

FAILED: drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
ccache cc -Idrivers/net/hns3/libhns3_sve_lib.a.p -Idrivers/net/hns3
-I../drivers/net/hns3 -Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig
-I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include
-Ilib/eal/arm/include -I../lib/eal/arm/include -Ilib/eal/common
-I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs
-I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry
-I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf
-Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter
-I../lib/meter -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -Werror -O3 -include rte_config.h -Wextra
-Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral
-Wformat-security -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
-march=armv8.1-a+crc+crypto -mcpu=thunderx2t99
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
-DCC_SVE_SUPPORT -march=armv8.2-a+sve -MD -MQ
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -MF
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o.d -o
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -c
../drivers/net/hns3/hns3_rxtx_vec_sve.c
cc1: error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’
switch [-Werror]
../drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error: arm_sve.h:
No such file or directory
    5 | #include <arm_sve.h>
      |          ^~~~~~~~~~~
cc1: all warnings being treated as errors
compilation terminated.


I see a similar issue on my fc32, cross compiling with following gcc:
$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
8.3-2019.03 (arm-rel-8.36)) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[74/503] Compiling C object
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
FAILED: drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
aarch64-linux-gnu-gcc -Idrivers/net/hns3/libhns3_sve_lib.a.p
-Idrivers/net/hns3 -I../../dpdk/drivers/net/hns3 -Ilib/ethdev
-I../../dpdk/lib/ethdev -I. -I../../dpdk -Iconfig -I../../dpdk/config
-Ilib/eal/include -I../../dpdk/lib/eal/include -Ilib/eal/linux/include
-I../../dpdk/lib/eal/linux/include -Ilib/eal/arm/include
-I../../dpdk/lib/eal/arm/include -Ilib/eal/common
-I../../dpdk/lib/eal/common -Ilib/eal -I../../dpdk/lib/eal
-Ilib/kvargs -I../../dpdk/lib/kvargs -Ilib/metrics
-I../../dpdk/lib/metrics -Ilib/telemetry -I../../dpdk/lib/telemetry
-Ilib/net -I../../dpdk/lib/net -Ilib/mbuf -I../../dpdk/lib/mbuf
-Ilib/mempool -I../../dpdk/lib/mempool -Ilib/ring
-I../../dpdk/lib/ring -Ilib/meter -I../../dpdk/lib/meter
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8-a+crc
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
-DCC_SVE_SUPPORT -march=armv8.2-a+sve -MD -MQ
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -MF
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o.d -o
drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -c
../../dpdk/drivers/net/hns3/hns3_rxtx_vec_sve.c
../../dpdk/drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error:
arm_sve.h: No such file or directory
 #include <arm_sve.h>
          ^~~~~~~~~~~
compilation terminated.


-- 
David Marchand

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/19/2021 9:08 AM, David Marchand wrote:
> On Tue, May 18, 2021 at 6:28 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
>> On 5/14/2021 3:12 PM, Honnappa Nagarahalli wrote:
>>> <snip>
>>>
>>>>
>>>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>>>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>>>
>>>> The solution:
>>>> a. If the minimum instruction set support SVE then compiles it.
>>>> b. Else if the compiler support SVE then compiles it.
>>>> c. Otherwise don't compile it.
>>>>
>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>
>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> Looks good to me.
>>> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>>>
>>
>> Applied to dpdk-next-net/main, thanks.
>>
>> (Only this patch, 2/2, applied, not whole set)
> 
> UNH caught a build regression on next-net and I think this is due to this patch:
> https://lab.dpdk.org/results/dashboard/tarballs/15259/
> 

Thanks David for heads up, yet it the reason of the error seems this patch, so I
will drop it from the next-net.


A few details from the error:

Default used compiler flag does not request SVE support, it is:
  Compiler for C supports arguments -march=armv8.1-a+crc+crypto: YES
  Compiler for C supports arguments -mcpu=thunderx2t99: YES
  Message: Using machine args: ['-march=armv8.1-a+crc+crypto', '-mcpu=thunderx2t99']

It is detected that compiler can support SVE:
  Compiler for C supports arguments -march=armv8.2-a+sve: YES

Because of the SVE support, driver tries to build 'hns3_rxtx_vec_sve.c' with SVE
support, even user doesn't request SVE, this is the design in the patch, build
command (stripped):
  -march=armv8.1-a+crc+crypto -mcpu=thunderx2t99 -DCC_SVE_SUPPORT
-march=armv8.2-a+sve ../drivers/net/hns3/hns3_rxtx_vec_sve.c

There are two errors:

1) appended '-march=armv8.2-a+sve' compiler argument to build
'hns3_rxtx_vec_sve.c' is conflicting with rest of the command:
  cc1: error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch
[-Werror]


2) SVE header is missing. When compiler supports the SVE, not sure why the
header is missing:
  ../drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error: arm_sve.h: No such
file or directory
    5 | #include <arm_sve.h>
      |          ^~~~~~~~~~~


> FAILED: drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
> ccache cc -Idrivers/net/hns3/libhns3_sve_lib.a.p -Idrivers/net/hns3
> -I../drivers/net/hns3 -Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig
> -I../config -Ilib/eal/include -I../lib/eal/include
> -Ilib/eal/linux/include -I../lib/eal/linux/include
> -Ilib/eal/arm/include -I../lib/eal/arm/include -Ilib/eal/common
> -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs
> -I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry
> -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf
> -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter
> -I../lib/meter -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
> -Wall -Winvalid-pch -Werror -O3 -include rte_config.h -Wextra
> -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral
> -Wformat-security -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings
> -Wno-address-of-packed-member -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
> -march=armv8.1-a+crc+crypto -mcpu=thunderx2t99
> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> -DCC_SVE_SUPPORT -march=armv8.2-a+sve -MD -MQ
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -MF
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o.d -o
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -c
> ../drivers/net/hns3/hns3_rxtx_vec_sve.c
> cc1: error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’
> switch [-Werror]
> ../drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error: arm_sve.h:
> No such file or directory
>     5 | #include <arm_sve.h>
>       |          ^~~~~~~~~~~
> cc1: all warnings being treated as errors
> compilation terminated.
> 
> 
> I see a similar issue on my fc32, cross compiling with following gcc:
> $ aarch64-linux-gnu-gcc --version
> aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> 8.3-2019.03 (arm-rel-8.36)) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> [74/503] Compiling C object
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
> FAILED: drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
> aarch64-linux-gnu-gcc -Idrivers/net/hns3/libhns3_sve_lib.a.p
> -Idrivers/net/hns3 -I../../dpdk/drivers/net/hns3 -Ilib/ethdev
> -I../../dpdk/lib/ethdev -I. -I../../dpdk -Iconfig -I../../dpdk/config
> -Ilib/eal/include -I../../dpdk/lib/eal/include -Ilib/eal/linux/include
> -I../../dpdk/lib/eal/linux/include -Ilib/eal/arm/include
> -I../../dpdk/lib/eal/arm/include -Ilib/eal/common
> -I../../dpdk/lib/eal/common -Ilib/eal -I../../dpdk/lib/eal
> -Ilib/kvargs -I../../dpdk/lib/kvargs -Ilib/metrics
> -I../../dpdk/lib/metrics -Ilib/telemetry -I../../dpdk/lib/telemetry
> -Ilib/net -I../../dpdk/lib/net -Ilib/mbuf -I../../dpdk/lib/mbuf
> -Ilib/mempool -I../../dpdk/lib/mempool -Ilib/ring
> -I../../dpdk/lib/ring -Ilib/meter -I../../dpdk/lib/meter
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
> -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wold-style-definition -Wpointer-arith -Wsign-compare
> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8-a+crc
> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
> -DCC_SVE_SUPPORT -march=armv8.2-a+sve -MD -MQ
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -MF
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o.d -o
> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -c
> ../../dpdk/drivers/net/hns3/hns3_rxtx_vec_sve.c
> ../../dpdk/drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error:
> arm_sve.h: No such file or directory
>  #include <arm_sve.h>
>           ^~~~~~~~~~~
> compilation terminated.
> 
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/19 17:27, Ferruh Yigit wrote:
> On 5/19/2021 9:08 AM, David Marchand wrote:
>> On Tue, May 18, 2021 at 6:28 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>>
>>> On 5/14/2021 3:12 PM, Honnappa Nagarahalli wrote:
>>>> <snip>
>>>>
>>>>>
>>>>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>>>>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>>>>
>>>>> The solution:
>>>>> a. If the minimum instruction set support SVE then compiles it.
>>>>> b. Else if the compiler support SVE then compiles it.
>>>>> c. Otherwise don't compile it.
>>>>>
>>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>>
>>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>>> Cc: stable@dpdk.org
>>>>>
>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>> Looks good to me.
>>>> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>>>>
>>>
>>> Applied to dpdk-next-net/main, thanks.
>>>
>>> (Only this patch, 2/2, applied, not whole set)
>>
>> UNH caught a build regression on next-net and I think this is due to this patch:
>> https://lab.dpdk.org/results/dashboard/tarballs/15259/
>>
> 
> Thanks David for heads up, yet it the reason of the error seems this patch, so I
> will drop it from the next-net.
> 
> 
> A few details from the error:
> 
> Default used compiler flag does not request SVE support, it is:
>   Compiler for C supports arguments -march=armv8.1-a+crc+crypto: YES
>   Compiler for C supports arguments -mcpu=thunderx2t99: YES
>   Message: Using machine args: ['-march=armv8.1-a+crc+crypto', '-mcpu=thunderx2t99']
> 
> It is detected that compiler can support SVE:
>   Compiler for C supports arguments -march=armv8.2-a+sve: YES
> 
> Because of the SVE support, driver tries to build 'hns3_rxtx_vec_sve.c' with SVE
> support, even user doesn't request SVE, this is the design in the patch, build
> command (stripped):
>   -march=armv8.1-a+crc+crypto -mcpu=thunderx2t99 -DCC_SVE_SUPPORT
> -march=armv8.2-a+sve ../drivers/net/hns3/hns3_rxtx_vec_sve.c
> 
> There are two errors:
> 
> 1) appended '-march=armv8.2-a+sve' compiler argument to build
> 'hns3_rxtx_vec_sve.c' is conflicting with rest of the command:
>   cc1: error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch
> [-Werror]
> 
> 
> 2) SVE header is missing. When compiler supports the SVE, not sure why the
> header is missing:
>   ../drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error: arm_sve.h: No such
> file or directory
>     5 | #include <arm_sve.h>
>       |          ^~~~~~~~~~~
> 

Sorry to introduce compilation errors.
Already fix in new patch: [dpdk-dev] [PATCH v2] net/hns3: fix compile error with gcc8.3 and thunderx2
@David could you help test?


We also found compile error with gcc8.3 with arm64_kunpeng930_linux_gcc (-march=-march=armv8.2-a+crypto+sve):
  In file included from ../dpdk-next-net/lib/eal/common/eal_common_options.c:38:
  ../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal error: arm_sve.h: No such file or directory
   #include <arm_sve.h>
          ^~~~~~~~~~~
  compilation terminated.
  [126/2250] Compiling C object lib/librte_net.a.p/net_rte_net_crc.c.o

the corresponding code:
  #ifdef __ARM_FEATURE_SVE
  #include <arm_sve.h>
  #endif

this is because gcc8.3 defined __ARM_FEATURE_SVE but it can't compile ACLE SVE code.
I will fix it later in 21.08

Best regards

> 
>> FAILED: drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
>> ccache cc -Idrivers/net/hns3/libhns3_sve_lib.a.p -Idrivers/net/hns3
>> -I../drivers/net/hns3 -Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig
>> -I../config -Ilib/eal/include -I../lib/eal/include
>> -Ilib/eal/linux/include -I../lib/eal/linux/include
>> -Ilib/eal/arm/include -I../lib/eal/arm/include -Ilib/eal/common
>> -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs
>> -I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry
>> -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf
>> -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter
>> -I../lib/meter -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
>> -Wall -Winvalid-pch -Werror -O3 -include rte_config.h -Wextra
>> -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral
>> -Wformat-security -Wmissing-declarations -Wmissing-prototypes
>> -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare
>> -Wstrict-prototypes -Wundef -Wwrite-strings
>> -Wno-address-of-packed-member -Wno-packed-not-aligned
>> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC
>> -march=armv8.1-a+crc+crypto -mcpu=thunderx2t99
>> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
>> -DCC_SVE_SUPPORT -march=armv8.2-a+sve -MD -MQ
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -MF
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o.d -o
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -c
>> ../drivers/net/hns3/hns3_rxtx_vec_sve.c
>> cc1: error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’
>> switch [-Werror]
>> ../drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error: arm_sve.h:
>> No such file or directory
>>     5 | #include <arm_sve.h>
>>       |          ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>> compilation terminated.
>>
>>
>> I see a similar issue on my fc32, cross compiling with following gcc:
>> $ aarch64-linux-gnu-gcc --version
>> aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
>> 8.3-2019.03 (arm-rel-8.36)) 8.3.0
>> Copyright (C) 2018 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> [74/503] Compiling C object
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
>> FAILED: drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o
>> aarch64-linux-gnu-gcc -Idrivers/net/hns3/libhns3_sve_lib.a.p
>> -Idrivers/net/hns3 -I../../dpdk/drivers/net/hns3 -Ilib/ethdev
>> -I../../dpdk/lib/ethdev -I. -I../../dpdk -Iconfig -I../../dpdk/config
>> -Ilib/eal/include -I../../dpdk/lib/eal/include -Ilib/eal/linux/include
>> -I../../dpdk/lib/eal/linux/include -Ilib/eal/arm/include
>> -I../../dpdk/lib/eal/arm/include -Ilib/eal/common
>> -I../../dpdk/lib/eal/common -Ilib/eal -I../../dpdk/lib/eal
>> -Ilib/kvargs -I../../dpdk/lib/kvargs -Ilib/metrics
>> -I../../dpdk/lib/metrics -Ilib/telemetry -I../../dpdk/lib/telemetry
>> -Ilib/net -I../../dpdk/lib/net -Ilib/mbuf -I../../dpdk/lib/mbuf
>> -Ilib/mempool -I../../dpdk/lib/mempool -Ilib/ring
>> -I../../dpdk/lib/ring -Ilib/meter -I../../dpdk/lib/meter
>> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall
>> -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
>> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
>> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
>> -Wold-style-definition -Wpointer-arith -Wsign-compare
>> -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned
>> -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8-a+crc
>> -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
>> -DCC_SVE_SUPPORT -march=armv8.2-a+sve -MD -MQ
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -MF
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o.d -o
>> drivers/net/hns3/libhns3_sve_lib.a.p/hns3_rxtx_vec_sve.c.o -c
>> ../../dpdk/drivers/net/hns3/hns3_rxtx_vec_sve.c
>> ../../dpdk/drivers/net/hns3/hns3_rxtx_vec_sve.c:5:10: fatal error:
>> arm_sve.h: No such file or directory
>>  #include <arm_sve.h>
>>           ^~~~~~~~~~~
>> compilation terminated.
>>
>>
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[David Marchand]

On Wed, May 19, 2021 at 2:17 PM fengchengwen <fengchengwen@huawei.com> wrote:
> We also found compile error with gcc8.3 with arm64_kunpeng930_linux_gcc (-march=-march=armv8.2-a+crypto+sve):
>   In file included from ../dpdk-next-net/lib/eal/common/eal_common_options.c:38:
>   ../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal error: arm_sve.h: No such file or directory
>    #include <arm_sve.h>
>           ^~~~~~~~~~~
>   compilation terminated.
>   [126/2250] Compiling C object lib/librte_net.a.p/net_rte_net_crc.c.o
>
> the corresponding code:
>   #ifdef __ARM_FEATURE_SVE
>   #include <arm_sve.h>
>   #endif
>
> this is because gcc8.3 defined __ARM_FEATURE_SVE but it can't compile ACLE SVE code.

Afaiu, gcc 8.3 does not define __ARM_FEATURE_SVE:

$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
8.3-2019.03 (arm-rel-8.36)) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ aarch64-linux-gnu-gcc - -pipe -E -P -D_FILE_OFFSET_BITS=64 -P -O0
-march=armv8-a+crc <<EOF
>         #ifndef __ARM_FEATURE_SVE
>         # define __ARM_FEATURE_SVE
>         #endif
>         "MESON_GET_DEFINE_DELIMITER"
> __ARM_FEATURE_SVE
> EOF
        "MESON_GET_DEFINE_DELIMITER"


-- 
David Marchand

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/19 20:37, David Marchand wrote:
> On Wed, May 19, 2021 at 2:17 PM fengchengwen <fengchengwen@huawei.com> wrote:
>> We also found compile error with gcc8.3 with arm64_kunpeng930_linux_gcc (-march=-march=armv8.2-a+crypto+sve):
>>   In file included from ../dpdk-next-net/lib/eal/common/eal_common_options.c:38:
>>   ../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal error: arm_sve.h: No such file or directory
>>    #include <arm_sve.h>
>>           ^~~~~~~~~~~
>>   compilation terminated.
>>   [126/2250] Compiling C object lib/librte_net.a.p/net_rte_net_crc.c.o
>>
>> the corresponding code:
>>   #ifdef __ARM_FEATURE_SVE
>>   #include <arm_sve.h>
>>   #endif
>>
>> this is because gcc8.3 defined __ARM_FEATURE_SVE but it can't compile ACLE SVE code.
> 
> Afaiu, gcc 8.3 does not define __ARM_FEATURE_SVE:
> 
> $ aarch64-linux-gnu-gcc --version
> aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> 8.3-2019.03 (arm-rel-8.36)) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> 
> $ aarch64-linux-gnu-gcc - -pipe -E -P -D_FILE_OFFSET_BITS=64 -P -O0
> -march=armv8-a+crc <<EOF
>>         #ifndef __ARM_FEATURE_SVE
>>         # define __ARM_FEATURE_SVE
>>         #endif
>>         "MESON_GET_DEFINE_DELIMITER"
>> __ARM_FEATURE_SVE
>> EOF
>         "MESON_GET_DEFINE_DELIMITER"
> 
> 

You should add sve in '-march' parameter, the same gcc version's output:

 ./aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

./aarch64-linux-gnu-gcc -march=armv8.2-a+sve -dM -E - </dev/null 2>&1 | grep SVE
#define __ARM_FEATURE_SVE 1
#define __ARM_FEATURE_SVE_BITS 0

./aarch64-linux-gnu-gcc -march=armv8-a+sve -dM -E - </dev/null 2>&1 | grep SVE
#define __ARM_FEATURE_SVE 1
#define __ARM_FEATURE_SVE_BITS 0

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/14/2021 10:53 AM, Chengwen Feng wrote:
> Currently, the SVE code is compiled only when -march supports SVE
> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
> approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 

Hi Chengwen,

As far as I understand from above problem statement, you want to produce a
binary that can run in two different platforms, one supports only NEON
instructions, other supports NEON + SVE.

For this driver should be compiled in a way to support min instruction set,
which is NEON.

There are two build items,

1) hns3_rxtx_vec_sve.c
2) rest of the library

There is already runtime checks to select Rx/Tx functions, so it is safe to
build (1) as long as compiler supports. If the platform doesn't support SVE, the
SVE path won't be selected during runtime.

For (2), it should be build to support NEON only, if it is compiled to support
SVE, it won't run on the platform that only supports NEON.

So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with SVE
support, won't this cause a problem on the NEON platform?

What do you think to only keep the else leg of the below check, which is if
compiler supports SVE, set '-DCC_SVE_SUPPORT' flag and only build (1) with SVE flag?

> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 13 +++++++++++++
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..8563d70 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,20 @@ deps += ['hash']
>  
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +        cflags += ['-DCC_SVE_SUPPORT']
>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve')
> +        cflags += ['-DCC_SVE_SUPPORT']
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Bruce Richardson]

On Tue, May 18, 2021 at 03:40:18PM +0100, Ferruh Yigit wrote:
> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
> > Currently, the SVE code is compiled only when -march supports SVE
> > (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
> > approach.
> > 
> > The solution:
> > a. If the minimum instruction set support SVE then compiles it.
> > b. Else if the compiler support SVE then compiles it.
> > c. Otherwise don't compile it.
> > 
> > [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> > 
> 
> Hi Chengwen,
> 
> As far as I understand from above problem statement, you want to produce a
> binary that can run in two different platforms, one supports only NEON
> instructions, other supports NEON + SVE.
> 
> For this driver should be compiled in a way to support min instruction set,
> which is NEON.
> 
> There are two build items,
> 
> 1) hns3_rxtx_vec_sve.c
> 2) rest of the library
> 
> There is already runtime checks to select Rx/Tx functions, so it is safe to
> build (1) as long as compiler supports. If the platform doesn't support SVE, the
> SVE path won't be selected during runtime.
> 
> For (2), it should be build to support NEON only, if it is compiled to support
> SVE, it won't run on the platform that only supports NEON.
> 
> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with SVE
> support, won't this cause a problem on the NEON platform?
> 
In that case, the rest of DPDK is being build with SVE so having one driver
neon-only doesn't really make sense.

Overall, the patch looks to mirror what we do for AVX2/AVX512 support in
the Intel drivers, so looks ok to me.

/Bruce

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/18/2021 4:15 PM, Bruce Richardson wrote:
> On Tue, May 18, 2021 at 03:40:18PM +0100, Ferruh Yigit wrote:
>> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
>>> Currently, the SVE code is compiled only when -march supports SVE
>>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>>> approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>
>> Hi Chengwen,
>>
>> As far as I understand from above problem statement, you want to produce a
>> binary that can run in two different platforms, one supports only NEON
>> instructions, other supports NEON + SVE.
>>
>> For this driver should be compiled in a way to support min instruction set,
>> which is NEON.
>>
>> There are two build items,
>>
>> 1) hns3_rxtx_vec_sve.c
>> 2) rest of the library
>>
>> There is already runtime checks to select Rx/Tx functions, so it is safe to
>> build (1) as long as compiler supports. If the platform doesn't support SVE, the
>> SVE path won't be selected during runtime.
>>
>> For (2), it should be build to support NEON only, if it is compiled to support
>> SVE, it won't run on the platform that only supports NEON.
>>
>> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with SVE
>> support, won't this cause a problem on the NEON platform?
>>
> In that case, the rest of DPDK is being build with SVE so having one driver
> neon-only doesn't really make sense.
> 
> Overall, the patch looks to mirror what we do for AVX2/AVX512 support in
> the Intel drivers, so looks ok to me.
> 

I agree there is no point to make driver specific change if whole DPDK build
with SVE, and that seems controlled by user as Honnappa clarified.
So I will proceed with patch, thanks.

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

<snip>
> 
> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
> > Currently, the SVE code is compiled only when -march supports SVE
> > (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
> > approach.
> >
> > The solution:
> > a. If the minimum instruction set support SVE then compiles it.
> > b. Else if the compiler support SVE then compiles it.
> > c. Otherwise don't compile it.
> >
> > [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >
> 
> Hi Chengwen,
> 
> As far as I understand from above problem statement, you want to produce a
> binary that can run in two different platforms, one supports only NEON
> instructions, other supports NEON + SVE.
> 
> For this driver should be compiled in a way to support min instruction set,
> which is NEON.
> 
> There are two build items,
> 
> 1) hns3_rxtx_vec_sve.c
> 2) rest of the library
> 
> There is already runtime checks to select Rx/Tx functions, so it is safe to build
> (1) as long as compiler supports. If the platform doesn't support SVE, the SVE
> path won't be selected during runtime.
> 
> For (2), it should be build to support NEON only, if it is compiled to support
> SVE, it won't run on the platform that only supports NEON.
> 
> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with
> SVE support, won't this cause a problem on the NEON platform?
The first if statement checks if the user has enabled SVE during compilation which indicates that the user will run the binary on a platform that has SVE (the minimum ISA level supported by this binary), hence it is ok to compile all the code with SVE.

If the user has not enabled SVE during compilation which indicates the user might run the binary on a platform that does not have SVE, the second if statement, checks if the compiler supports SVE. If yes, it will compile the SVE version of the driver as well and the run time checks choose the correct version.

> 
> What do you think to only keep the else leg of the below check, which is if
> compiler supports SVE, set '-DCC_SVE_SUPPORT' flag and only build (1) with
> SVE flag?
> 
> > Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> > Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > ---
> >  drivers/net/hns3/hns3_rxtx.c |  2 +-
> >  drivers/net/hns3/meson.build | 13 +++++++++++++
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/hns3/hns3_rxtx.c
> > b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> > --- a/drivers/net/hns3/hns3_rxtx.c
> > +++ b/drivers/net/hns3/hns3_rxtx.c
> > @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >  static bool
> >  hns3_get_sve_support(void)
> >  {
> > -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> > +#if defined(CC_SVE_SUPPORT)
> >  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >  		return false;
> >  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> > diff --git a/drivers/net/hns3/meson.build
> > b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
> > --- a/drivers/net/hns3/meson.build
> > +++ b/drivers/net/hns3/meson.build
> > @@ -35,7 +35,20 @@ deps += ['hash']
> >
> >  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >      sources += files('hns3_rxtx_vec.c')
> > +
> > +    # compile SVE when:
> > +    # a. support SVE in minimum instruction set baseline
> > +    # b. it's not minimum instruction set, but compiler support
> >      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> > +        cflags += ['-DCC_SVE_SUPPORT']
> >          sources += files('hns3_rxtx_vec_sve.c')
> > +    elif cc.has_argument('-march=armv8.2-a+sve')
> > +        cflags += ['-DCC_SVE_SUPPORT']
> > +        hns3_sve_lib = static_library('hns3_sve_lib',
> > +                        'hns3_rxtx_vec_sve.c',
> > +                        dependencies: [static_rte_ethdev],
> > +                        include_directories: includes,
> > +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> > +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >      endif
> >  endif
> >

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/18/2021 4:48 PM, Honnappa Nagarahalli wrote:
> <snip>
>>
>> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
>>> Currently, the SVE code is compiled only when -march supports SVE
>>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>>> approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>
>> Hi Chengwen,
>>
>> As far as I understand from above problem statement, you want to produce a
>> binary that can run in two different platforms, one supports only NEON
>> instructions, other supports NEON + SVE.
>>
>> For this driver should be compiled in a way to support min instruction set,
>> which is NEON.
>>
>> There are two build items,
>>
>> 1) hns3_rxtx_vec_sve.c
>> 2) rest of the library
>>
>> There is already runtime checks to select Rx/Tx functions, so it is safe to build
>> (1) as long as compiler supports. If the platform doesn't support SVE, the SVE
>> path won't be selected during runtime.
>>
>> For (2), it should be build to support NEON only, if it is compiled to support
>> SVE, it won't run on the platform that only supports NEON.
>>
>> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with
>> SVE support, won't this cause a problem on the NEON platform?
> The first if statement checks if the user has enabled SVE during compilation which indicates that the user will run the binary on a platform that has SVE (the minimum ISA level supported by this binary), hence it is ok to compile all the code with SVE.
> 

So it is related to the what user provided (I assume as compiler flag), instead
of host HW capability.

> If the user has not enabled SVE during compilation which indicates the user might run the binary on a platform that does not have SVE, the second if statement, checks if the compiler supports SVE. If yes, it will compile the SVE version of the driver as well and the run time checks choose the correct version.
> 

OK, this sounds good, thanks for clarification.

>>
>> What do you think to only keep the else leg of the below check, which is if
>> compiler supports SVE, set '-DCC_SVE_SUPPORT' flag and only build (1) with
>> SVE flag?
>>
>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>> ---
>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>>  drivers/net/hns3/meson.build | 13 +++++++++++++
>>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>  static bool
>>>  hns3_get_sve_support(void)
>>>  {
>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>> +#if defined(CC_SVE_SUPPORT)
>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>  		return false;
>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>> diff --git a/drivers/net/hns3/meson.build
>>> b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
>>> --- a/drivers/net/hns3/meson.build
>>> +++ b/drivers/net/hns3/meson.build
>>> @@ -35,7 +35,20 @@ deps += ['hash']
>>>
>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>      sources += files('hns3_rxtx_vec.c')
>>> +
>>> +    # compile SVE when:
>>> +    # a. support SVE in minimum instruction set baseline
>>> +    # b. it's not minimum instruction set, but compiler support
>>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>          sources += files('hns3_rxtx_vec_sve.c')
>>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>> +                        'hns3_rxtx_vec_sve.c',
>>> +                        dependencies: [static_rte_ethdev],
>>> +                        include_directories: includes,
>>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>      endif
>>>  endif
>>>
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Honnappa Nagarahalli]

> > <snip>
> >>
> >> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
> >>> Currently, the SVE code is compiled only when -march supports SVE
> >>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
> >>> approach.
> >>>
> >>> The solution:
> >>> a. If the minimum instruction set support SVE then compiles it.
> >>> b. Else if the compiler support SVE then compiles it.
> >>> c. Otherwise don't compile it.
> >>>
> >>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>>
> >>
> >> Hi Chengwen,
> >>
> >> As far as I understand from above problem statement, you want to
> >> produce a binary that can run in two different platforms, one
> >> supports only NEON instructions, other supports NEON + SVE.
> >>
> >> For this driver should be compiled in a way to support min
> >> instruction set, which is NEON.
> >>
> >> There are two build items,
> >>
> >> 1) hns3_rxtx_vec_sve.c
> >> 2) rest of the library
> >>
> >> There is already runtime checks to select Rx/Tx functions, so it is
> >> safe to build
> >> (1) as long as compiler supports. If the platform doesn't support
> >> SVE, the SVE path won't be selected during runtime.
> >>
> >> For (2), it should be build to support NEON only, if it is compiled
> >> to support SVE, it won't run on the platform that only supports NEON.
> >>
> >> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is
> >> build with SVE support, won't this cause a problem on the NEON platform?
> > The first if statement checks if the user has enabled SVE during compilation
> which indicates that the user will run the binary on a platform that has SVE
> (the minimum ISA level supported by this binary), hence it is ok to compile all
> the code with SVE.
> >
> 
> So it is related to the what user provided (I assume as compiler flag), instead
> of host HW capability.
It is the HW host capability as provided in the compiler flag. It is coming from config/arm/meson.build.

> 
> > If the user has not enabled SVE during compilation which indicates the user
> might run the binary on a platform that does not have SVE, the second if
> statement, checks if the compiler supports SVE. If yes, it will compile the SVE
> version of the driver as well and the run time checks choose the correct
> version.
> >
> 
> OK, this sounds good, thanks for clarification.
> 
> >>
> >> What do you think to only keep the else leg of the below check, which
> >> is if compiler supports SVE, set '-DCC_SVE_SUPPORT' flag and only
> >> build (1) with SVE flag?
> >>
> >>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >>> Cc: stable@dpdk.org
> >>>
> >>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>> ---
> >>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
> >>> | 13 +++++++++++++
> >>>  2 files changed, 14 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> >>> --- a/drivers/net/hns3/hns3_rxtx.c
> >>> +++ b/drivers/net/hns3/hns3_rxtx.c
> >>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >>>  static bool
> >>>  hns3_get_sve_support(void)
> >>>  {
> >>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >>> +#if defined(CC_SVE_SUPPORT)
> >>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >>>  		return false;
> >>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >>> diff --git a/drivers/net/hns3/meson.build
> >>> b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
> >>> --- a/drivers/net/hns3/meson.build
> >>> +++ b/drivers/net/hns3/meson.build
> >>> @@ -35,7 +35,20 @@ deps += ['hash']
> >>>
> >>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >>>      sources += files('hns3_rxtx_vec.c')
> >>> +
> >>> +    # compile SVE when:
> >>> +    # a. support SVE in minimum instruction set baseline
> >>> +    # b. it's not minimum instruction set, but compiler support
> >>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >>> +        cflags += ['-DCC_SVE_SUPPORT']
> >>>          sources += files('hns3_rxtx_vec_sve.c')
> >>> +    elif cc.has_argument('-march=armv8.2-a+sve')
> >>> +        cflags += ['-DCC_SVE_SUPPORT']
> >>> +        hns3_sve_lib = static_library('hns3_sve_lib',
> >>> +                        'hns3_rxtx_vec_sve.c',
> >>> +                        dependencies: [static_rte_ethdev],
> >>> +                        include_directories: includes,
> >>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
> >>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >>>      endif
> >>>  endif
> >>>
> >

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/18/2021 5:12 PM, Honnappa Nagarahalli wrote:
>>> <snip>
>>>>
>>>> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
>>>>> Currently, the SVE code is compiled only when -march supports SVE
>>>>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>>>>> approach.
>>>>>
>>>>> The solution:
>>>>> a. If the minimum instruction set support SVE then compiles it.
>>>>> b. Else if the compiler support SVE then compiles it.
>>>>> c. Otherwise don't compile it.
>>>>>
>>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>>
>>>>
>>>> Hi Chengwen,
>>>>
>>>> As far as I understand from above problem statement, you want to
>>>> produce a binary that can run in two different platforms, one
>>>> supports only NEON instructions, other supports NEON + SVE.
>>>>
>>>> For this driver should be compiled in a way to support min
>>>> instruction set, which is NEON.
>>>>
>>>> There are two build items,
>>>>
>>>> 1) hns3_rxtx_vec_sve.c
>>>> 2) rest of the library
>>>>
>>>> There is already runtime checks to select Rx/Tx functions, so it is
>>>> safe to build
>>>> (1) as long as compiler supports. If the platform doesn't support
>>>> SVE, the SVE path won't be selected during runtime.
>>>>
>>>> For (2), it should be build to support NEON only, if it is compiled
>>>> to support SVE, it won't run on the platform that only supports NEON.
>>>>
>>>> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is
>>>> build with SVE support, won't this cause a problem on the NEON platform?
>>> The first if statement checks if the user has enabled SVE during compilation
>> which indicates that the user will run the binary on a platform that has SVE
>> (the minimum ISA level supported by this binary), hence it is ok to compile all
>> the code with SVE.
>>>
>>
>> So it is related to the what user provided (I assume as compiler flag), instead
>> of host HW capability.
> It is the HW host capability as provided in the compiler flag. It is coming from config/arm/meson.build.
> 

Is this patch has dependency to 1/2, that updates 'config/arm/meson.build'?

What I understand is, if user provides compiler argument to request SVE,
something like '-march=armv8.2-a+sve', and host HW supports it, whole driver
will be built with SVE support.

If user not request SVE, driver won't be compiled with SVE support even if HW
support it, but only 'hns3_rxtx_vec_sve.c' will be compiled if compiler supports
SVE.

Is above correct and does it have any dependency to first patch, I thought this
is independent from first patch.


>>
>>> If the user has not enabled SVE during compilation which indicates the user
>> might run the binary on a platform that does not have SVE, the second if
>> statement, checks if the compiler supports SVE. If yes, it will compile the SVE
>> version of the driver as well and the run time checks choose the correct
>> version.
>>>
>>
>> OK, this sounds good, thanks for clarification.
>>
>>>>
>>>> What do you think to only keep the else leg of the below check, which
>>>> is if compiler supports SVE, set '-DCC_SVE_SUPPORT' flag and only
>>>> build (1) with SVE flag?
>>>>
>>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>>> Cc: stable@dpdk.org
>>>>>
>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>> ---
>>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
>>>>> | 13 +++++++++++++
>>>>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>>>  static bool
>>>>>  hns3_get_sve_support(void)
>>>>>  {
>>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>>>> +#if defined(CC_SVE_SUPPORT)
>>>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>>>  		return false;
>>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>>>> diff --git a/drivers/net/hns3/meson.build
>>>>> b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
>>>>> --- a/drivers/net/hns3/meson.build
>>>>> +++ b/drivers/net/hns3/meson.build
>>>>> @@ -35,7 +35,20 @@ deps += ['hash']
>>>>>
>>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>>>      sources += files('hns3_rxtx_vec.c')
>>>>> +
>>>>> +    # compile SVE when:
>>>>> +    # a. support SVE in minimum instruction set baseline
>>>>> +    # b. it's not minimum instruction set, but compiler support
>>>>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>>>          sources += files('hns3_rxtx_vec_sve.c')
>>>>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>>>> +                        'hns3_rxtx_vec_sve.c',
>>>>> +                        dependencies: [static_rte_ethdev],
>>>>> +                        include_directories: includes,
>>>>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>>>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>>>      endif
>>>>>  endif
>>>>>
>>>
> 

Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/19 0:37, Ferruh Yigit wrote:
> On 5/18/2021 5:12 PM, Honnappa Nagarahalli wrote:
>>>> <snip>
>>>>>
>>>>> On 5/14/2021 10:53 AM, Chengwen Feng wrote:
>>>>>> Currently, the SVE code is compiled only when -march supports SVE
>>>>>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>>>>>> approach.
>>>>>>
>>>>>> The solution:
>>>>>> a. If the minimum instruction set support SVE then compiles it.
>>>>>> b. Else if the compiler support SVE then compiles it.
>>>>>> c. Otherwise don't compile it.
>>>>>>
>>>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>>>
>>>>>
>>>>> Hi Chengwen,
>>>>>
>>>>> As far as I understand from above problem statement, you want to
>>>>> produce a binary that can run in two different platforms, one
>>>>> supports only NEON instructions, other supports NEON + SVE.
>>>>>
>>>>> For this driver should be compiled in a way to support min
>>>>> instruction set, which is NEON.
>>>>>
>>>>> There are two build items,
>>>>>
>>>>> 1) hns3_rxtx_vec_sve.c
>>>>> 2) rest of the library
>>>>>
>>>>> There is already runtime checks to select Rx/Tx functions, so it is
>>>>> safe to build
>>>>> (1) as long as compiler supports. If the platform doesn't support
>>>>> SVE, the SVE path won't be selected during runtime.
>>>>>
>>>>> For (2), it should be build to support NEON only, if it is compiled
>>>>> to support SVE, it won't run on the platform that only supports NEON.
>>>>>
>>>>> So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is
>>>>> build with SVE support, won't this cause a problem on the NEON platform?
>>>> The first if statement checks if the user has enabled SVE during compilation
>>> which indicates that the user will run the binary on a platform that has SVE
>>> (the minimum ISA level supported by this binary), hence it is ok to compile all
>>> the code with SVE.
>>>>
>>>
>>> So it is related to the what user provided (I assume as compiler flag), instead
>>> of host HW capability.
>> It is the HW host capability as provided in the compiler flag. It is coming from config/arm/meson.build.
>>
> 
> Is this patch has dependency to 1/2, that updates 'config/arm/meson.build'?
> 
> What I understand is, if user provides compiler argument to request SVE,
> something like '-march=armv8.2-a+sve', and host HW supports it, whole driver
> will be built with SVE support.
> 
> If user not request SVE, driver won't be compiled with SVE support even if HW
> support it, but only 'hns3_rxtx_vec_sve.c' will be compiled if compiler supports
> SVE.
> 
> Is above correct and does it have any dependency to first patch, I thought this
> is independent from first patch.
> 

Yes, you are right, it's independent from first patch.

> 
>>>
>>>> If the user has not enabled SVE during compilation which indicates the user
>>> might run the binary on a platform that does not have SVE, the second if
>>> statement, checks if the compiler supports SVE. If yes, it will compile the SVE
>>> version of the driver as well and the run time checks choose the correct
>>> version.
>>>>
>>>
>>> OK, this sounds good, thanks for clarification.
>>>
>>>>>
>>>>> What do you think to only keep the else leg of the below check, which
>>>>> is if compiler supports SVE, set '-DCC_SVE_SUPPORT' flag and only
>>>>> build (1) with SVE flag?
>>>>>
>>>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>>>> Cc: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>>> ---
>>>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
>>>>>> | 13 +++++++++++++
>>>>>>  2 files changed, 14 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>>>>  static bool
>>>>>>  hns3_get_sve_support(void)
>>>>>>  {
>>>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>>>>> +#if defined(CC_SVE_SUPPORT)
>>>>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>>>>  		return false;
>>>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>>>>> diff --git a/drivers/net/hns3/meson.build
>>>>>> b/drivers/net/hns3/meson.build index 53c7df7..8563d70 100644
>>>>>> --- a/drivers/net/hns3/meson.build
>>>>>> +++ b/drivers/net/hns3/meson.build
>>>>>> @@ -35,7 +35,20 @@ deps += ['hash']
>>>>>>
>>>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>>>>      sources += files('hns3_rxtx_vec.c')
>>>>>> +
>>>>>> +    # compile SVE when:
>>>>>> +    # a. support SVE in minimum instruction set baseline
>>>>>> +    # b. it's not minimum instruction set, but compiler support
>>>>>>      if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>>>>          sources += files('hns3_rxtx_vec_sve.c')
>>>>>> +    elif cc.has_argument('-march=armv8.2-a+sve')
>>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>>>>> +                        'hns3_rxtx_vec_sve.c',
>>>>>> +                        dependencies: [static_rte_ethdev],
>>>>>> +                        include_directories: includes,
>>>>>> +                        c_args: [cflags, '-march=armv8.2-a+sve'])
>>>>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>>>>      endif
>>>>>>  endif
>>>>>>
>>>>
>>
> 
> 
> .
> 

[dpdk-dev] [PATCH v6 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v6:
* fix compile error with gcc8.3 and thunder2 of 2/2 patch
v5:
* make sure 'march_feature' parsed depend on 'march_base'
* only the kunpeng930 use the new option
v4:
* fix compile option combine problem of 1/2 patch
v3:
* fix checkpatch error of 1/2 patch
* modify comments of 1/2 patch
v2:
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select most suitable -march for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 31 +++++++++++++++++++++++++++++--
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
 3 files changed, 50 insertions(+), 4 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v6 1/2] config/arm: select most suitable -march for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature': ['crypto', 'sve']
Note: If user defined 'march_feature', it also needs to define a valid
'march_base' because 'march_feature' depends on 'march_base' when
checking validity.
3. Select the most suitable march+feature combination based on
'march_base' and 'march_feature' tuples.
4. Use the selected march+feature combination as the default
machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..044812f 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -158,7 +158,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base': ['-march=armv8.2-a'],
+            'march_feature': ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +451,33 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the most suitable march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        tmp_machine_march = ''
+        march_valid = false
+        foreach march: part_number_config['march_base']
+            if cc.has_argument(march)
+                tmp_machine_march = march # Set the higher supported march as possible
+                march_valid = true
+            endif
+        endforeach
+        # select feature only when march valid
+        if march_valid and part_number_config.has_key('march_feature')
+            foreach feature: part_number_config['march_feature']
+                tmp_feature = tmp_machine_march + '+' + feature
+                if cc.has_argument(tmp_feature)
+                    tmp_machine_march = tmp_feature # Set the more supported feature as possible
+                endif
+            endforeach
+        endif
+        if march_valid
+            machine_march = [tmp_machine_march]
+        endif
+    endif
+
     # apply supported machine args
-    machine_args = [] # Clear previous machine args
+    machine_args = machine_march # Init with machine march which set above
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

Re: [dpdk-dev] [PATCH v6 1/2] config/arm: select most suitable -march for kunpeng soc

[Jerin Jacob]

On Wed, May 19, 2021 at 6:58 PM Chengwen Feng <fengchengwen@huawei.com> wrote:
>
> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> but some compiler doesn't recognize the march because it doesn't
> support sve.
>
> To solve this bug we use the following scheme:
> 1. Define 'march_base' tuple which defines support march, it should
> arrange from lower to higher.
> e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a']
> 2. Define 'march_feature' tuple which defines support feature.
> e.g. 'march_feature': ['crypto', 'sve']
> Note: If user defined 'march_feature', it also needs to define a valid
> 'march_base' because 'march_feature' depends on 'march_base' when
> checking validity.
> 3. Select the most suitable march+feature combination based on
> 'march_base' and 'march_feature' tuples.
> 4. Use the selected march+feature combination as the default
> machine_args.
>
> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  config/arm/meson.build | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 3f34ec9..044812f 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -158,7 +158,9 @@ implementer_hisilicon = {
>              ]
>          },
>          '0xd02': {
> -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> +            'march_base': ['-march=armv8.2-a'],
> +            'march_feature': ['crypto', 'sve'],
> +            'machine_args': [],

IMO, This patch must split into two as this problem is not specific to kunpeng
patch 1: config/arm: infrastructure to add most suitable -march or
so(This will have only infra)
patch 2: config/arm: update the targets to support most suitable
-march or so(This one will one will have changes for all targets
including kunpeng)




>              'flags': [
>                  ['RTE_MACHINE', '"Kunpeng 930"'],
>                  ['RTE_ARM_FEATURE_ATOMICS', true],
> @@ -449,8 +451,33 @@ else
>      # add/overwrite flags in the proper order
>      dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
>
> +    # select the most suitable march+feature combination
> +    machine_march = []
> +    if part_number_config.has_key('march_base')
> +        tmp_machine_march = ''
> +        march_valid = false
> +        foreach march: part_number_config['march_base']
> +            if cc.has_argument(march)
> +                tmp_machine_march = march # Set the higher supported march as possible
> +                march_valid = true
> +            endif
> +        endforeach
> +        # select feature only when march valid
> +        if march_valid and part_number_config.has_key('march_feature')

I think, in order to make more generic, IMO, it should be
1) List all the march and features options(crypto, sve)
2) Probe the compiler to find the supported march, features
3) In each target,
- define the minimum march and features
- define the the best need march and features
4) If the compiler support the best config, pick that
else
5) If the compiler supports the minimum config, pick that
else
6) Don't build and throw the error.


> +            foreach feature: part_number_config['march_feature']
> +                tmp_feature = tmp_machine_march + '+' + feature
> +                if cc.has_argument(tmp_feature)
> +                    tmp_machine_march = tmp_feature # Set the more supported feature as possible
> +                endif
> +            endforeach
> +        endif
> +        if march_valid
> +            machine_march = [tmp_machine_march]
> +        endif
> +    endif
> +
>      # apply supported machine args
> -    machine_args = [] # Clear previous machine args
> +    machine_args = machine_march # Init with machine march which set above
>      foreach flag: part_number_config['machine_args']
>          if cc.has_argument(flag)
>              machine_args += flag
> --
> 2.8.1
>

Re: [dpdk-dev] [PATCH v6 1/2] config/arm: select most suitable -march for kunpeng soc

[Honnappa Nagarahalli]

<snip>
> 
> On Wed, May 19, 2021 at 6:58 PM Chengwen Feng
> <fengchengwen@huawei.com> wrote:
> >
> > Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> > but some compiler doesn't recognize the march because it doesn't
> > support sve.
> >
> > To solve this bug we use the following scheme:
> > 1. Define 'march_base' tuple which defines support march, it should
> > arrange from lower to higher.
> > e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a'] 2. Define
> > 'march_feature' tuple which defines support feature.
> > e.g. 'march_feature': ['crypto', 'sve']
> > Note: If user defined 'march_feature', it also needs to define a valid
> > 'march_base' because 'march_feature' depends on 'march_base' when
> > checking validity.
> > 3. Select the most suitable march+feature combination based on
> > 'march_base' and 'march_feature' tuples.
> > 4. Use the selected march+feature combination as the default
> > machine_args.
> >
> > Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> > ---
> >  config/arm/meson.build | 31 +++++++++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 3f34ec9..044812f 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -158,7 +158,9 @@ implementer_hisilicon = {
> >              ]
> >          },
> >          '0xd02': {
> > -            'machine_args': ['-march=armv8.2-a+crypto+sve'],
> > +            'march_base': ['-march=armv8.2-a'],
> > +            'march_feature': ['crypto', 'sve'],
> > +            'machine_args': [],
> 
> IMO, This patch must split into two as this problem is not specific to kunpeng
> patch 1: config/arm: infrastructure to add most suitable -march or so(This will
> have only infra) patch 2: config/arm: update the targets to support most
> suitable -march or so(This one will one will have changes for all targets
> including kunpeng)
> 
> 
> 
> 
> >              'flags': [
> >                  ['RTE_MACHINE', '"Kunpeng 930"'],
> >                  ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8 +451,33
> > @@ else
> >      # add/overwrite flags in the proper order
> >      dpdk_flags = flags_common + implementer_config['flags'] +
> > part_number_config.get('flags', []) + soc_flags
> >
> > +    # select the most suitable march+feature combination
> > +    machine_march = []
> > +    if part_number_config.has_key('march_base')
> > +        tmp_machine_march = ''
> > +        march_valid = false
> > +        foreach march: part_number_config['march_base']
> > +            if cc.has_argument(march)
> > +                tmp_machine_march = march # Set the higher supported march
> as possible
> > +                march_valid = true
> > +            endif
> > +        endforeach
> > +        # select feature only when march valid
> > +        if march_valid and
> > + part_number_config.has_key('march_feature')
> 
> I think, in order to make more generic, IMO, it should be
> 1) List all the march and features options(crypto, sve)
> 2) Probe the compiler to find the supported march, features
> 3) In each target,
> - define the minimum march and features
I think we should list the max march supported by the target. We can use that to go back in decreasing order to identify the march the compiler supports.
We would need a list of features between those marchs + any additional features the target supports. We can probe those features in compiler to add the support for those features.
I am thinking this will not require us to throw an error.


> - define the the best need march and features
> 4) If the compiler support the best config, pick that else
> 5) If the compiler supports the minimum config, pick that else
> 6) Don't build and throw the error.
> 
> 
> > +            foreach feature: part_number_config['march_feature']
> > +                tmp_feature = tmp_machine_march + '+' + feature
> > +                if cc.has_argument(tmp_feature)
> > +                    tmp_machine_march = tmp_feature # Set the more supported
> feature as possible
> > +                endif
> > +            endforeach
> > +        endif
> > +        if march_valid
> > +            machine_march = [tmp_machine_march]
> > +        endif
> > +    endif
> > +
> >      # apply supported machine args
> > -    machine_args = [] # Clear previous machine args
> > +    machine_args = machine_march # Init with machine march which set
> > + above
> >      foreach flag: part_number_config['machine_args']
> >          if cc.has_argument(flag)
> >              machine_args += flag
> > --
> > 2.8.1
> >

[dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..5f9af9b 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,26 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
-    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
+    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
+        cflags += ['-DCC_SVE_SUPPORT']
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
+        sve_cflags = ['-DCC_SVE_SUPPORT']
+        foreach flag: cflags
+            # filterout -march -mcpu -mtune
+            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
+                sve_cflags += flag
+            endif
+        endforeach
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/19/2021 2:25 PM, Chengwen Feng wrote:
> Currently, the SVE code is compiled only when -march supports SVE
> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
> approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>

The patch passes the CI build [1], but in that test sve file is not compiled at
all because of missing header file [2].

I wonder if the warning caused by conflicting switch [3] is still valid, we need
a platform that sve file is compiled to verify this. Do you have this
environment, that sets '-mcpu=armv8.1-a'.


Btw, CI reports unit test failure, I don't think it is related with this patch
but can you please double check?



[1]
https://lab.dpdk.org/results/dashboard/patchsets/17135/

[2]
Check usable header "arm_sve.h" : NO

[3]
error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch [-Werror]

> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..5f9af9b 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,26 @@ deps += ['hash']
>  
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
> +        cflags += ['-DCC_SVE_SUPPORT']
>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
> +        sve_cflags = ['-DCC_SVE_SUPPORT']
> +        foreach flag: cflags
> +            # filterout -march -mcpu -mtune
> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
> +                sve_cflags += flag
> +            endif
> +        endforeach
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> 

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/19 23:02, Ferruh Yigit wrote:
> On 5/19/2021 2:25 PM, Chengwen Feng wrote:
>> Currently, the SVE code is compiled only when -march supports SVE
>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>> approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> 
> The patch passes the CI build [1], but in that test sve file is not compiled at
> all because of missing header file [2].
> 

Yes, it was designed as it.
In hns3 meson.build we call cc.check_header('arm_sve.h'), and gcc9 don't have this headerfile.

> I wonder if the warning caused by conflicting switch [3] is still valid, we need
> a platform that sve file is compiled to verify this. Do you have this
> environment, that sets '-mcpu=armv8.1-a'.
> 

It already fix by filterout '-march' '-mcpu' '-mtune' in hns3 meson.build of this patch
If don't add the above filtout logic:
  a) Test result with gcc8.3 and crossfile thunder2:
    cc1: warning: switch ‘-mcpu=thunderx2t99’ conflicts with ‘-march=armv8.2-a+sve’ switch
  b) Test result with gcc9.2 and crossfile thunder2:
    cc1: warning: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch

Note: the gcc8.3/9.2 version detail:
  ./aarch64-linux-gnu-gcc --version
  aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0
  ./aarch64-none-linux-gnu-gcc --version
  aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025

> 
> Btw, CI reports unit test failure, I don't think it is related with this patch
> but can you please double check?
> 

Agree, it is atomic_autotest and malloc_autotest failed, it hasn't run any hns3 driver's code.

> 
> 
> [1]
> https://lab.dpdk.org/results/dashboard/patchsets/17135/
> 
> [2]
> Check usable header "arm_sve.h" : NO
> 
> [3]
> error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch [-Werror]
> 
>> ---
>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>  drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>> index 1d7a769..4ef20c6 100644
>> --- a/drivers/net/hns3/hns3_rxtx.c
>> +++ b/drivers/net/hns3/hns3_rxtx.c
>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>  static bool
>>  hns3_get_sve_support(void)
>>  {
>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>> +#if defined(CC_SVE_SUPPORT)
>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>  		return false;
>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>> index 53c7df7..5f9af9b 100644
>> --- a/drivers/net/hns3/meson.build
>> +++ b/drivers/net/hns3/meson.build
>> @@ -35,7 +35,26 @@ deps += ['hash']
>>  
>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>      sources += files('hns3_rxtx_vec.c')
>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>> +
>> +    # compile SVE when:
>> +    # a. support SVE in minimum instruction set baseline
>> +    # b. it's not minimum instruction set, but compiler support
>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
>> +        cflags += ['-DCC_SVE_SUPPORT']
>>          sources += files('hns3_rxtx_vec_sve.c')
>> +    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>> +        foreach flag: cflags
>> +            # filterout -march -mcpu -mtune
>> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
>> +                sve_cflags += flag
>> +            endif
>> +        endforeach
>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>> +                        'hns3_rxtx_vec_sve.c',
>> +                        dependencies: [static_rte_ethdev],
>> +                        include_directories: includes,
>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>      endif
>>  endif
>>
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Ferruh Yigit]

On 5/20/2021 2:11 AM, fengchengwen wrote:
> 
> 
> On 2021/5/19 23:02, Ferruh Yigit wrote:
>> On 5/19/2021 2:25 PM, Chengwen Feng wrote:
>>> Currently, the SVE code is compiled only when -march supports SVE
>>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>>> approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>
>> The patch passes the CI build [1], but in that test sve file is not compiled at
>> all because of missing header file [2].
>>
> 
> Yes, it was designed as it.
> In hns3 meson.build we call cc.check_header('arm_sve.h'), and gcc9 don't have this headerfile.
> 
>> I wonder if the warning caused by conflicting switch [3] is still valid, we need
>> a platform that sve file is compiled to verify this. Do you have this
>> environment, that sets '-mcpu=armv8.1-a'.
>>
> 
> It already fix by filterout '-march' '-mcpu' '-mtune' in hns3 meson.build of this patch
> If don't add the above filtout logic:
>   a) Test result with gcc8.3 and crossfile thunder2:
>     cc1: warning: switch ‘-mcpu=thunderx2t99’ conflicts with ‘-march=armv8.2-a+sve’ switch
>   b) Test result with gcc9.2 and crossfile thunder2:
>     cc1: warning: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch
> 
> Note: the gcc8.3/9.2 version detail:
>   ./aarch64-linux-gnu-gcc --version
>   aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0
>   ./aarch64-none-linux-gnu-gcc --version
>   aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025
> 

Hi Chengwen,

-rc4 is already out and release is planned for tomorrow, so it is late to get
this patch now, let's proceed with it in next release.

>>
>> Btw, CI reports unit test failure, I don't think it is related with this patch
>> but can you please double check?
>>
> 
> Agree, it is atomic_autotest and malloc_autotest failed, it hasn't run any hns3 driver's code.
> 
>>
>>
>> [1]
>> https://lab.dpdk.org/results/dashboard/patchsets/17135/
>>
>> [2]
>> Check usable header "arm_sve.h" : NO
>>
>> [3]
>> error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch [-Werror]
>>
>>> ---
>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>>  drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
>>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>>> index 1d7a769..4ef20c6 100644
>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>  static bool
>>>  hns3_get_sve_support(void)
>>>  {
>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>> +#if defined(CC_SVE_SUPPORT)
>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>  		return false;
>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>>> index 53c7df7..5f9af9b 100644
>>> --- a/drivers/net/hns3/meson.build
>>> +++ b/drivers/net/hns3/meson.build
>>> @@ -35,7 +35,26 @@ deps += ['hash']
>>>  
>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>      sources += files('hns3_rxtx_vec.c')
>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>> +
>>> +    # compile SVE when:
>>> +    # a. support SVE in minimum instruction set baseline
>>> +    # b. it's not minimum instruction set, but compiler support
>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>          sources += files('hns3_rxtx_vec_sve.c')
>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>>> +        foreach flag: cflags
>>> +            # filterout -march -mcpu -mtune
>>> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
>>> +                sve_cflags += flag
>>> +            endif
>>> +        endforeach
>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>> +                        'hns3_rxtx_vec_sve.c',
>>> +                        dependencies: [static_rte_ethdev],
>>> +                        include_directories: includes,
>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>      endif
>>>  endif
>>>
>>
>>
>> .
>>
> 

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Ruifeng Wang]

> -----Original Message-----
> From: Chengwen Feng <fengchengwen@huawei.com>
> Sent: Wednesday, May 19, 2021 9:26 PM
> To: thomas@monjalon.net; ferruh.yigit@intel.com
> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
> bruce.richardson@intel.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> 
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..5f9af9b 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,26 @@ deps += ['hash']
> 
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
> cc.check_header('arm_sve.h')
> +        cflags += ['-DCC_SVE_SUPPORT']
With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.

[1] http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send-email-fengchengwen@huawei.com/

>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
> +        sve_cflags = ['-DCC_SVE_SUPPORT']
> +        foreach flag: cflags
> +            # filterout -march -mcpu -mtune
> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
> flag.startswith('-mtune='))
> +                sve_cflags += flag
> +            endif
> +        endforeach
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> --
> 2.8.1

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/20 16:24, Ruifeng Wang wrote:
>> -----Original Message-----
>> From: Chengwen Feng <fengchengwen@huawei.com>
>> Sent: Wednesday, May 19, 2021 9:26 PM
>> To: thomas@monjalon.net; ferruh.yigit@intel.com
>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
>> bruce.richardson@intel.com; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>  drivers/net/hns3/meson.build | 21 ++++++++++++++++++++-
>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>> index 1d7a769..4ef20c6 100644
>> --- a/drivers/net/hns3/hns3_rxtx.c
>> +++ b/drivers/net/hns3/hns3_rxtx.c
>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>  static bool
>>  hns3_get_sve_support(void)
>>  {
>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>> +#if defined(CC_SVE_SUPPORT)
>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>  		return false;
>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>> index 53c7df7..5f9af9b 100644
>> --- a/drivers/net/hns3/meson.build
>> +++ b/drivers/net/hns3/meson.build
>> @@ -35,7 +35,26 @@ deps += ['hash']
>>
>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>      sources += files('hns3_rxtx_vec.c')
>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>> +
>> +    # compile SVE when:
>> +    # a. support SVE in minimum instruction set baseline
>> +    # b. it's not minimum instruction set, but compiler support
>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
>> cc.check_header('arm_sve.h')
>> +        cflags += ['-DCC_SVE_SUPPORT']
> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
> 

The CC_SVE_ACLE_SUPPORT was defined under default machine_args which support SVE,
it can't deals with the situation: the default machine_args don't support SVE
but compiler support SVE.
So the CC_SVE_SUPPORT marco is necessary.

> [1] http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send-email-fengchengwen@huawei.com/
> 
>>          sources += files('hns3_rxtx_vec_sve.c')
>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
>> cc.check_header('arm_sve.h')
>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>> +        foreach flag: cflags
>> +            # filterout -march -mcpu -mtune
>> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
>> flag.startswith('-mtune='))
>> +                sve_cflags += flag
>> +            endif
>> +        endforeach
>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>> +                        'hns3_rxtx_vec_sve.c',
>> +                        dependencies: [static_rte_ethdev],
>> +                        include_directories: includes,
>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>      endif
>>  endif
>> --
>> 2.8.1
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Ruifeng Wang]

> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Thursday, May 20, 2021 6:55 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
> ferruh.yigit@intel.com
> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
> bruce.richardson@intel.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> 
> 
> 
> On 2021/5/20 16:24, Ruifeng Wang wrote:
> >> -----Original Message-----
> >> From: Chengwen Feng <fengchengwen@huawei.com>
> >> Sent: Wednesday, May 19, 2021 9:26 PM
> >> To: thomas@monjalon.net; ferruh.yigit@intel.com
> >> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
> >> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
> >> bruce.richardson@intel.com; Honnappa Nagarahalli
> >> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> >> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> >> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> >>
> >> Currently, the SVE code is compiled only when -march supports SVE
> >> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
> approach.
> >>
> >> The solution:
> >> a. If the minimum instruction set support SVE then compiles it.
> >> b. Else if the compiler support SVE then compiles it.
> >> c. Otherwise don't compile it.
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>
> >> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >> ---
> >>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build |
> >> 21 ++++++++++++++++++++-
> >>  2 files changed, 21 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> >> --- a/drivers/net/hns3/hns3_rxtx.c
> >> +++ b/drivers/net/hns3/hns3_rxtx.c
> >> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >>  static bool
> >>  hns3_get_sve_support(void)
> >>  {
> >> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >> +#if defined(CC_SVE_SUPPORT)
> >>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >>  		return false;
> >>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >> diff --git a/drivers/net/hns3/meson.build
> >> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
> >> --- a/drivers/net/hns3/meson.build
> >> +++ b/drivers/net/hns3/meson.build
> >> @@ -35,7 +35,26 @@ deps += ['hash']
> >>
> >>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >>      sources += files('hns3_rxtx_vec.c')
> >> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >> +
> >> +    # compile SVE when:
> >> +    # a. support SVE in minimum instruction set baseline
> >> +    # b. it's not minimum instruction set, but compiler support
> >> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >> + and
> >> cc.check_header('arm_sve.h')
> >> +        cflags += ['-DCC_SVE_SUPPORT']
> > With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
> > Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
> >
> 
> The CC_SVE_ACLE_SUPPORT was defined under default machine_args which
> support SVE, it can't deals with the situation: the default machine_args don't
> support SVE but compiler support SVE.
> So the CC_SVE_SUPPORT marco is necessary.
Agree that macro for SVE is also needed here. And we can also use '-DCC_SVE_ACLE_SUPPORT' here right?
I think there is no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT when they are used in source code.
IMO the same macro name can be used, and it removes redundancy and confusion. 

> 
> > [1]
> > http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send
> > -email-fengchengwen@huawei.com/
> >
> >>          sources += files('hns3_rxtx_vec_sve.c')
> >> +    elif cc.has_argument('-march=armv8.2-a+sve') and
> >> cc.check_header('arm_sve.h')
> >> +        sve_cflags = ['-DCC_SVE_SUPPORT']
> >> +        foreach flag: cflags
> >> +            # filterout -march -mcpu -mtune
> >> +            if not (flag.startswith('-march=') or
> >> + flag.startswith('-mcpu=') or
> >> flag.startswith('-mtune='))
> >> +                sve_cflags += flag
> >> +            endif
> >> +        endforeach
> >> +        hns3_sve_lib = static_library('hns3_sve_lib',
> >> +                        'hns3_rxtx_vec_sve.c',
> >> +                        dependencies: [static_rte_ethdev],
> >> +                        include_directories: includes,
> >> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> >> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >>      endif
> >>  endif
> >> --
> >> 2.8.1
> >
> >
> > .
> >

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/21 13:21, Ruifeng Wang wrote:
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Thursday, May 20, 2021 6:55 PM
>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>> ferruh.yigit@intel.com
>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>> bruce.richardson@intel.com; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>>
>>
>> On 2021/5/20 16:24, Ruifeng Wang wrote:
>>>> -----Original Message-----
>>>> From: Chengwen Feng <fengchengwen@huawei.com>
>>>> Sent: Wednesday, May 19, 2021 9:26 PM
>>>> To: thomas@monjalon.net; ferruh.yigit@intel.com
>>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
>>>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>>>
>>>> Currently, the SVE code is compiled only when -march supports SVE
>>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
>> approach.
>>>>
>>>> The solution:
>>>> a. If the minimum instruction set support SVE then compiles it.
>>>> b. Else if the compiler support SVE then compiles it.
>>>> c. Otherwise don't compile it.
>>>>
>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>
>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>> ---
>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build |
>>>> 21 ++++++++++++++++++++-
>>>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>>  static bool
>>>>  hns3_get_sve_support(void)
>>>>  {
>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>>> +#if defined(CC_SVE_SUPPORT)
>>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>>  		return false;
>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>>> diff --git a/drivers/net/hns3/meson.build
>>>> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
>>>> --- a/drivers/net/hns3/meson.build
>>>> +++ b/drivers/net/hns3/meson.build
>>>> @@ -35,7 +35,26 @@ deps += ['hash']
>>>>
>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>>      sources += files('hns3_rxtx_vec.c')
>>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>> +
>>>> +    # compile SVE when:
>>>> +    # a. support SVE in minimum instruction set baseline
>>>> +    # b. it's not minimum instruction set, but compiler support
>>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>> + and
>>>> cc.check_header('arm_sve.h')
>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
>>>
>>
>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args which
>> support SVE, it can't deals with the situation: the default machine_args don't
>> support SVE but compiler support SVE.
>> So the CC_SVE_SUPPORT marco is necessary.
> Agree that macro for SVE is also needed here. And we can also use '-DCC_SVE_ACLE_SUPPORT' here right?
> I think there is no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT when they are used in source code.
> IMO the same macro name can be used, and it removes redundancy and confusion. 
> 

You are right, no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT
But the hns3 sve already support 20.11, and CC_SVE_ACLE_SUPPORT was newly defined,
there maybe some problems when backporting.

Or we could redefine CC_SVE_ACLE_SUPPORT under default machine_args:
    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
        cflags += ['-DCC_SVE_ACLE_SUPPORT']
        sources += files('hns3_rxtx_vec_sve.c')
    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
        sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
        foreach flag: cflags
            # filterout -march -mcpu -mtune
            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
                sve_cflags += flag
            endif
        endforeach
but this way may introduce coupling, I think.

>>
>>> [1]
>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send
>>> -email-fengchengwen@huawei.com/
>>>
>>>>          sources += files('hns3_rxtx_vec_sve.c')
>>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
>>>> cc.check_header('arm_sve.h')
>>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>>>> +        foreach flag: cflags
>>>> +            # filterout -march -mcpu -mtune
>>>> +            if not (flag.startswith('-march=') or
>>>> + flag.startswith('-mcpu=') or
>>>> flag.startswith('-mtune='))
>>>> +                sve_cflags += flag
>>>> +            endif
>>>> +        endforeach
>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>>> +                        'hns3_rxtx_vec_sve.c',
>>>> +                        dependencies: [static_rte_ethdev],
>>>> +                        include_directories: includes,
>>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>>      endif
>>>>  endif
>>>> --
>>>> 2.8.1
>>>
>>>
>>> .
>>>
> 

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Ruifeng Wang]

> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Friday, May 21, 2021 2:53 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
> ferruh.yigit@intel.com
> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
> bruce.richardson@intel.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> 
> 
> 
> On 2021/5/21 13:21, Ruifeng Wang wrote:
> >> -----Original Message-----
> >> From: fengchengwen <fengchengwen@huawei.com>
> >> Sent: Thursday, May 20, 2021 6:55 PM
> >> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
> >> ferruh.yigit@intel.com
> >> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
> >> bruce.richardson@intel.com; Honnappa Nagarahalli
> >> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> >> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> >> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile
> >> method
> >>
> >>
> >>
> >> On 2021/5/20 16:24, Ruifeng Wang wrote:
> >>>> -----Original Message-----
> >>>> From: Chengwen Feng <fengchengwen@huawei.com>
> >>>> Sent: Wednesday, May 19, 2021 9:26 PM
> >>>> To: thomas@monjalon.net; ferruh.yigit@intel.com
> >>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
> >>>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
> >>>> bruce.richardson@intel.com; Honnappa Nagarahalli
> >>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> >>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> >>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> >>>>
> >>>> Currently, the SVE code is compiled only when -march supports SVE
> >>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with
> >>>> this
> >> approach.
> >>>>
> >>>> The solution:
> >>>> a. If the minimum instruction set support SVE then compiles it.
> >>>> b. Else if the compiler support SVE then compiles it.
> >>>> c. Otherwise don't compile it.
> >>>>
> >>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>>>
> >>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >>>> Cc: stable@dpdk.org
> >>>>
> >>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>>> ---
> >>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
> >>>> |
> >>>> 21 ++++++++++++++++++++-
> >>>>  2 files changed, 21 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> >>>> --- a/drivers/net/hns3/hns3_rxtx.c
> >>>> +++ b/drivers/net/hns3/hns3_rxtx.c
> >>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >>>>  static bool
> >>>>  hns3_get_sve_support(void)
> >>>>  {
> >>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >>>> +#if defined(CC_SVE_SUPPORT)
> >>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >>>>  		return false;
> >>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >>>> diff --git a/drivers/net/hns3/meson.build
> >>>> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
> >>>> --- a/drivers/net/hns3/meson.build
> >>>> +++ b/drivers/net/hns3/meson.build
> >>>> @@ -35,7 +35,26 @@ deps += ['hash']
> >>>>
> >>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >>>>      sources += files('hns3_rxtx_vec.c')
> >>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >>>> +
> >>>> +    # compile SVE when:
> >>>> +    # a. support SVE in minimum instruction set baseline
> >>>> +    # b. it's not minimum instruction set, but compiler support
> >>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >>>> + and
> >>>> cc.check_header('arm_sve.h')
> >>>> +        cflags += ['-DCC_SVE_SUPPORT']
> >>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
> >>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
> >>>
> >>
> >> The CC_SVE_ACLE_SUPPORT was defined under default machine_args
> which
> >> support SVE, it can't deals with the situation: the default
> >> machine_args don't support SVE but compiler support SVE.
> >> So the CC_SVE_SUPPORT marco is necessary.
> > Agree that macro for SVE is also needed here. And we can also use '-
> DCC_SVE_ACLE_SUPPORT' here right?
> > I think there is no difference between CC_SVE_ACLE_SUPPORT and
> CC_SVE_SUPPORT when they are used in source code.
> > IMO the same macro name can be used, and it removes redundancy and
> confusion.
> >
> 
> You are right, no difference between CC_SVE_ACLE_SUPPORT and
> CC_SVE_SUPPORT But the hns3 sve already support 20.11, and
> CC_SVE_ACLE_SUPPORT was newly defined, there maybe some problems
> when backporting.
20.11 release has no machine enabled SVE extension. 

> 
> Or we could redefine CC_SVE_ACLE_SUPPORT under default machine_args:
>     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
> cc.check_header('arm_sve.h')
>         cflags += ['-DCC_SVE_ACLE_SUPPORT']
'if dpdk_conf.get(CC_SVE_ACLE_SUPPORT)' should be fine?
Stable branch has no SVE enabled in machine_args.

>         sources += files('hns3_rxtx_vec_sve.c')
>     elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
This is fine. Macro name is consistent.

>         foreach flag: cflags
>             # filterout -march -mcpu -mtune
>             if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
> flag.startswith('-mtune='))
>                 sve_cflags += flag
>             endif
>         endforeach
> but this way may introduce coupling, I think.
> 
> >>
> >>> [1]
> >>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-se
> >>> nd
> >>> -email-fengchengwen@huawei.com/
> >>>
> >>>>          sources += files('hns3_rxtx_vec_sve.c')
> >>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
> >>>> cc.check_header('arm_sve.h')
> >>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
> >>>> +        foreach flag: cflags
> >>>> +            # filterout -march -mcpu -mtune
> >>>> +            if not (flag.startswith('-march=') or
> >>>> + flag.startswith('-mcpu=') or
> >>>> flag.startswith('-mtune='))
> >>>> +                sve_cflags += flag
> >>>> +            endif
> >>>> +        endforeach
> >>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
> >>>> +                        'hns3_rxtx_vec_sve.c',
> >>>> +                        dependencies: [static_rte_ethdev],
> >>>> +                        include_directories: includes,
> >>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> >>>> +        objs +=
> >>>> + hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >>>>      endif
> >>>>  endif
> >>>> --
> >>>> 2.8.1
> >>>
> >>>
> >>> .
> >>>
> >

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

On 2021/5/24 13:38, Ruifeng Wang wrote:
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Friday, May 21, 2021 2:53 PM
>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>> ferruh.yigit@intel.com
>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>> bruce.richardson@intel.com; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>>
>>
>> On 2021/5/21 13:21, Ruifeng Wang wrote:
>>>> -----Original Message-----
>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>> Sent: Thursday, May 20, 2021 6:55 PM
>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>>>> ferruh.yigit@intel.com
>>>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile
>>>> method
>>>>
>>>>
>>>>
>>>> On 2021/5/20 16:24, Ruifeng Wang wrote:
>>>>>> -----Original Message-----
>>>>>> From: Chengwen Feng <fengchengwen@huawei.com>
>>>>>> Sent: Wednesday, May 19, 2021 9:26 PM
>>>>>> To: thomas@monjalon.net; ferruh.yigit@intel.com
>>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
>>>>>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
>>>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>>>>>
>>>>>> Currently, the SVE code is compiled only when -march supports SVE
>>>>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with
>>>>>> this
>>>> approach.
>>>>>>
>>>>>> The solution:
>>>>>> a. If the minimum instruction set support SVE then compiles it.
>>>>>> b. Else if the compiler support SVE then compiles it.
>>>>>> c. Otherwise don't compile it.
>>>>>>
>>>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>>>
>>>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>>>> Cc: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>>> ---
>>>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build
>>>>>> |
>>>>>> 21 ++++++++++++++++++++-
>>>>>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>>>>  static bool
>>>>>>  hns3_get_sve_support(void)
>>>>>>  {
>>>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>>>>> +#if defined(CC_SVE_SUPPORT)
>>>>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>>>>  		return false;
>>>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>>>>> diff --git a/drivers/net/hns3/meson.build
>>>>>> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
>>>>>> --- a/drivers/net/hns3/meson.build
>>>>>> +++ b/drivers/net/hns3/meson.build
>>>>>> @@ -35,7 +35,26 @@ deps += ['hash']
>>>>>>
>>>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>>>>      sources += files('hns3_rxtx_vec.c')
>>>>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>>>> +
>>>>>> +    # compile SVE when:
>>>>>> +    # a. support SVE in minimum instruction set baseline
>>>>>> +    # b. it's not minimum instruction set, but compiler support
>>>>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>>>> + and
>>>>>> cc.check_header('arm_sve.h')
>>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
>>>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
>>>>>
>>>>
>>>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args
>> which
>>>> support SVE, it can't deals with the situation: the default
>>>> machine_args don't support SVE but compiler support SVE.
>>>> So the CC_SVE_SUPPORT marco is necessary.
>>> Agree that macro for SVE is also needed here. And we can also use '-
>> DCC_SVE_ACLE_SUPPORT' here right?
>>> I think there is no difference between CC_SVE_ACLE_SUPPORT and
>> CC_SVE_SUPPORT when they are used in source code.
>>> IMO the same macro name can be used, and it removes redundancy and
>> confusion.
>>>
>>
>> You are right, no difference between CC_SVE_ACLE_SUPPORT and
>> CC_SVE_SUPPORT But the hns3 sve already support 20.11, and
>> CC_SVE_ACLE_SUPPORT was newly defined, there maybe some problems
>> when backporting.
> 20.11 release has no machine enabled SVE extension. 
> 
>>
>> Or we could redefine CC_SVE_ACLE_SUPPORT under default machine_args:
>>     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
>> cc.check_header('arm_sve.h')
>>         cflags += ['-DCC_SVE_ACLE_SUPPORT']
> 'if dpdk_conf.get(CC_SVE_ACLE_SUPPORT)' should be fine?
> Stable branch has no SVE enabled in machine_args.
> 

But 20.11 use could use hns3 SVE path when compile with gcc10.

If we reuse the CC_SVE_ACLE_SUPPORT macro, there maybe problem when backporting:
a. In 21.08 we could depend on CC_SVE_ACLE_SUPPORT, so it will be:
    if dpdk_conf.get('CC_SVE_ACLE_SUPPORT')
        sources += files('hns3_rxtx_vec_sve.c')
    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
        sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
        ...
b. But for backport to 20.11, we should use another impl:
    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
        cflags += ['-DCC_SVE_ACLE_SUPPORT']
        sources += files('hns3_rxtx_vec_sve.c')
    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
        sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
        ...
As you see, the above two are not unified.

So here I think use the CC_SVE_SUPPORT is appropriate.

@Ferruh  what's your opinion ?

>>         sources += files('hns3_rxtx_vec_sve.c')
>>     elif cc.has_argument('-march=armv8.2-a+sve') and
>> cc.check_header('arm_sve.h')
>>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
> This is fine. Macro name is consistent.
> 
>>         foreach flag: cflags
>>             # filterout -march -mcpu -mtune
>>             if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
>> flag.startswith('-mtune='))
>>                 sve_cflags += flag
>>             endif
>>         endforeach
>> but this way may introduce coupling, I think.
>>
>>>>
>>>>> [1]
>>>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-se
>>>>> nd
>>>>> -email-fengchengwen@huawei.com/
>>>>>
>>>>>>          sources += files('hns3_rxtx_vec_sve.c')
>>>>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
>>>>>> cc.check_header('arm_sve.h')
>>>>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>>>>>> +        foreach flag: cflags
>>>>>> +            # filterout -march -mcpu -mtune
>>>>>> +            if not (flag.startswith('-march=') or
>>>>>> + flag.startswith('-mcpu=') or
>>>>>> flag.startswith('-mtune='))
>>>>>> +                sve_cflags += flag
>>>>>> +            endif
>>>>>> +        endforeach
>>>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>>>>> +                        'hns3_rxtx_vec_sve.c',
>>>>>> +                        dependencies: [static_rte_ethdev],
>>>>>> +                        include_directories: includes,
>>>>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>>>>>> +        objs +=
>>>>>> + hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>>>>      endif
>>>>>>  endif
>>>>>> --
>>>>>> 2.8.1
>>>>>
>>>>>
>>>>> .
>>>>>
>>>
> 

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[Ruifeng Wang]

> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Monday, May 24, 2021 4:44 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
> ferruh.yigit@intel.com
> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
> bruce.richardson@intel.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> 
> 
> 
> On 2021/5/24 13:38, Ruifeng Wang wrote:
> >> -----Original Message-----
> >> From: fengchengwen <fengchengwen@huawei.com>
> >> Sent: Friday, May 21, 2021 2:53 PM
> >> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
> >> ferruh.yigit@intel.com
> >> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
> >> bruce.richardson@intel.com; Honnappa Nagarahalli
> >> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> >> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> >> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile
> >> method
> >>
> >>
> >>
> >> On 2021/5/21 13:21, Ruifeng Wang wrote:
> >>>> -----Original Message-----
> >>>> From: fengchengwen <fengchengwen@huawei.com>
> >>>> Sent: Thursday, May 20, 2021 6:55 PM
> >>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
> >>>> ferruh.yigit@intel.com
> >>>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
> >>>> bruce.richardson@intel.com; Honnappa Nagarahalli
> >>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> >>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> >>>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile
> >>>> method
> >>>>
> >>>>
> >>>>
> >>>> On 2021/5/20 16:24, Ruifeng Wang wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Chengwen Feng <fengchengwen@huawei.com>
> >>>>>> Sent: Wednesday, May 19, 2021 9:26 PM
> >>>>>> To: thomas@monjalon.net; ferruh.yigit@intel.com
> >>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
> >>>>>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
> >>>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
> >>>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> >>>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> >>>>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile
> >>>>>> method
> >>>>>>
> >>>>>> Currently, the SVE code is compiled only when -march supports SVE
> >>>>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with
> >>>>>> this
> >>>> approach.
> >>>>>>
> >>>>>> The solution:
> >>>>>> a. If the minimum instruction set support SVE then compiles it.
> >>>>>> b. Else if the compiler support SVE then compiles it.
> >>>>>> c. Otherwise don't compile it.
> >>>>>>
> >>>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>>>>>
> >>>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >>>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >>>>>> Cc: stable@dpdk.org
> >>>>>>
> >>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> >>>>>> ---
> >>>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
> >>>>>> drivers/net/hns3/meson.build
> >>>>>> |
> >>>>>> 21 ++++++++++++++++++++-
> >>>>>>  2 files changed, 21 insertions(+), 2 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >>>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> >>>>>> --- a/drivers/net/hns3/hns3_rxtx.c
> >>>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
> >>>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >>>>>>  static bool
> >>>>>>  hns3_get_sve_support(void)
> >>>>>>  {
> >>>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >>>>>> +#if defined(CC_SVE_SUPPORT)
> >>>>>>  	if (rte_vect_get_max_simd_bitwidth() <
> RTE_VECT_SIMD_256)
> >>>>>>  		return false;
> >>>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >>>>>> diff --git a/drivers/net/hns3/meson.build
> >>>>>> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
> >>>>>> --- a/drivers/net/hns3/meson.build
> >>>>>> +++ b/drivers/net/hns3/meson.build
> >>>>>> @@ -35,7 +35,26 @@ deps += ['hash']
> >>>>>>
> >>>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >>>>>>      sources += files('hns3_rxtx_vec.c')
> >>>>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >>>>>> +
> >>>>>> +    # compile SVE when:
> >>>>>> +    # a. support SVE in minimum instruction set baseline
> >>>>>> +    # b. it's not minimum instruction set, but compiler support
> >>>>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) !=
> ''
> >>>>>> + and
> >>>>>> cc.check_header('arm_sve.h')
> >>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
> >>>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
> >>>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
> >>>>>
> >>>>
> >>>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args
> >> which
> >>>> support SVE, it can't deals with the situation: the default
> >>>> machine_args don't support SVE but compiler support SVE.
> >>>> So the CC_SVE_SUPPORT marco is necessary.
> >>> Agree that macro for SVE is also needed here. And we can also use '-
> >> DCC_SVE_ACLE_SUPPORT' here right?
> >>> I think there is no difference between CC_SVE_ACLE_SUPPORT and
> >> CC_SVE_SUPPORT when they are used in source code.
> >>> IMO the same macro name can be used, and it removes redundancy and
> >> confusion.
> >>>
> >>
> >> You are right, no difference between CC_SVE_ACLE_SUPPORT and
> >> CC_SVE_SUPPORT But the hns3 sve already support 20.11, and
> >> CC_SVE_ACLE_SUPPORT was newly defined, there maybe some
> problems when
> >> backporting.
> > 20.11 release has no machine enabled SVE extension.
> >
> >>
> >> Or we could redefine CC_SVE_ACLE_SUPPORT under default
> machine_args:
> >>     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >> and
> >> cc.check_header('arm_sve.h')
> >>         cflags += ['-DCC_SVE_ACLE_SUPPORT']
> > 'if dpdk_conf.get(CC_SVE_ACLE_SUPPORT)' should be fine?
> > Stable branch has no SVE enabled in machine_args.
> >
> 
> But 20.11 use could use hns3 SVE path when compile with gcc10.
20.11 user will be able to use hns3 SVE path. 
Implementation 'a' should be fine for both 20.11 and 21.08.

> 
> If we reuse the CC_SVE_ACLE_SUPPORT macro, there maybe problem when
> backporting:
> a. In 21.08 we could depend on CC_SVE_ACLE_SUPPORT, so it will be:
>     if dpdk_conf.get('CC_SVE_ACLE_SUPPORT')
>         sources += files('hns3_rxtx_vec_sve.c')
>     elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
gcc10 user will go into this branch, and SVE path will be included.
It is identical in 'a' and 'b'.

>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
>         ...
> b. But for backport to 20.11, we should use another impl:
>     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
> cc.check_header('arm_sve.h')
'if' clause in implementation 'a' will have the same behavior as this one in 20.11.
 Both of the checks will be false. 
'CC_SVE_ACLE_SUPPORT' is not defined in 20.11 -> result in false.
No machine_args have sve enabled in 20.11 -> result in false.
So I think there is a chance we can use a single macro.

>         cflags += ['-DCC_SVE_ACLE_SUPPORT']
>         sources += files('hns3_rxtx_vec_sve.c')
>     elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
>         ...
> As you see, the above two are not unified.
> 
> So here I think use the CC_SVE_SUPPORT is appropriate.
> 
> @Ferruh  what's your opinion ?
> 
> >>         sources += files('hns3_rxtx_vec_sve.c')
> >>     elif cc.has_argument('-march=armv8.2-a+sve') and
> >> cc.check_header('arm_sve.h')
> >>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
> > This is fine. Macro name is consistent.
> >
> >>         foreach flag: cflags
> >>             # filterout -march -mcpu -mtune
> >>             if not (flag.startswith('-march=') or
> >> flag.startswith('-mcpu=') or
> >> flag.startswith('-mtune='))
> >>                 sve_cflags += flag
> >>             endif
> >>         endforeach
> >> but this way may introduce coupling, I think.
> >>
> >>>>
> >>>>> [1]
> >>>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-
> git-
> >>>>> se
> >>>>> nd
> >>>>> -email-fengchengwen@huawei.com/
> >>>>>
> >>>>>>          sources += files('hns3_rxtx_vec_sve.c')
> >>>>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
> >>>>>> cc.check_header('arm_sve.h')
> >>>>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
> >>>>>> +        foreach flag: cflags
> >>>>>> +            # filterout -march -mcpu -mtune
> >>>>>> +            if not (flag.startswith('-march=') or
> >>>>>> + flag.startswith('-mcpu=') or
> >>>>>> flag.startswith('-mtune='))
> >>>>>> +                sve_cflags += flag
> >>>>>> +            endif
> >>>>>> +        endforeach
> >>>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
> >>>>>> +                        'hns3_rxtx_vec_sve.c',
> >>>>>> +                        dependencies: [static_rte_ethdev],
> >>>>>> +                        include_directories: includes,
> >>>>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> >>>>>> +        objs +=
> >>>>>> + hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >>>>>>      endif
> >>>>>>  endif
> >>>>>> --
> >>>>>> 2.8.1
> >>>>>
> >>>>>
> >>>>> .
> >>>>>
> >>>
> >

Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

Fix in v7, thanks

On 2021/5/24 18:03, Ruifeng Wang wrote:
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Monday, May 24, 2021 4:44 PM
>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>> ferruh.yigit@intel.com
>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>> bruce.richardson@intel.com; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>>
>>
>> On 2021/5/24 13:38, Ruifeng Wang wrote:
>>>> -----Original Message-----
>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>> Sent: Friday, May 21, 2021 2:53 PM
>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>>>> ferruh.yigit@intel.com
>>>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile
>>>> method
>>>>
>>>>
>>>>
>>>> On 2021/5/21 13:21, Ruifeng Wang wrote:
>>>>>> -----Original Message-----
>>>>>> From: fengchengwen <fengchengwen@huawei.com>
>>>>>> Sent: Thursday, May 20, 2021 6:55 PM
>>>>>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>>>>>> ferruh.yigit@intel.com
>>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>>>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>>>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile
>>>>>> method
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2021/5/20 16:24, Ruifeng Wang wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Chengwen Feng <fengchengwen@huawei.com>
>>>>>>>> Sent: Wednesday, May 19, 2021 9:26 PM
>>>>>>>> To: thomas@monjalon.net; ferruh.yigit@intel.com
>>>>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
>>>>>>>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
>>>>>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>>>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>>>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>>>>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile
>>>>>>>> method
>>>>>>>>
>>>>>>>> Currently, the SVE code is compiled only when -march supports SVE
>>>>>>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with
>>>>>>>> this
>>>>>> approach.
>>>>>>>>
>>>>>>>> The solution:
>>>>>>>> a. If the minimum instruction set support SVE then compiles it.
>>>>>>>> b. Else if the compiler support SVE then compiles it.
>>>>>>>> c. Otherwise don't compile it.
>>>>>>>>
>>>>>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>>>>>
>>>>>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>>>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>>>>>> Cc: stable@dpdk.org
>>>>>>>>
>>>>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>>>>> ---
>>>>>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>>>>>>>> drivers/net/hns3/meson.build
>>>>>>>> |
>>>>>>>> 21 ++++++++++++++++++++-
>>>>>>>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>>>>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>>>>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>>>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>>>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>>>>>>  static bool
>>>>>>>>  hns3_get_sve_support(void)
>>>>>>>>  {
>>>>>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>>>>>>> +#if defined(CC_SVE_SUPPORT)
>>>>>>>>  	if (rte_vect_get_max_simd_bitwidth() <
>> RTE_VECT_SIMD_256)
>>>>>>>>  		return false;
>>>>>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>>>>>>> diff --git a/drivers/net/hns3/meson.build
>>>>>>>> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
>>>>>>>> --- a/drivers/net/hns3/meson.build
>>>>>>>> +++ b/drivers/net/hns3/meson.build
>>>>>>>> @@ -35,7 +35,26 @@ deps += ['hash']
>>>>>>>>
>>>>>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>>>>>>      sources += files('hns3_rxtx_vec.c')
>>>>>>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>>>>>> +
>>>>>>>> +    # compile SVE when:
>>>>>>>> +    # a. support SVE in minimum instruction set baseline
>>>>>>>> +    # b. it's not minimum instruction set, but compiler support
>>>>>>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) !=
>> ''
>>>>>>>> + and
>>>>>>>> cc.check_header('arm_sve.h')
>>>>>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>>>>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
>>>>>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
>>>>>>>
>>>>>>
>>>>>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args
>>>> which
>>>>>> support SVE, it can't deals with the situation: the default
>>>>>> machine_args don't support SVE but compiler support SVE.
>>>>>> So the CC_SVE_SUPPORT marco is necessary.
>>>>> Agree that macro for SVE is also needed here. And we can also use '-
>>>> DCC_SVE_ACLE_SUPPORT' here right?
>>>>> I think there is no difference between CC_SVE_ACLE_SUPPORT and
>>>> CC_SVE_SUPPORT when they are used in source code.
>>>>> IMO the same macro name can be used, and it removes redundancy and
>>>> confusion.
>>>>>
>>>>
>>>> You are right, no difference between CC_SVE_ACLE_SUPPORT and
>>>> CC_SVE_SUPPORT But the hns3 sve already support 20.11, and
>>>> CC_SVE_ACLE_SUPPORT was newly defined, there maybe some
>> problems when
>>>> backporting.
>>> 20.11 release has no machine enabled SVE extension.
>>>
>>>>
>>>> Or we could redefine CC_SVE_ACLE_SUPPORT under default
>> machine_args:
>>>>     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>> and
>>>> cc.check_header('arm_sve.h')
>>>>         cflags += ['-DCC_SVE_ACLE_SUPPORT']
>>> 'if dpdk_conf.get(CC_SVE_ACLE_SUPPORT)' should be fine?
>>> Stable branch has no SVE enabled in machine_args.
>>>
>>
>> But 20.11 use could use hns3 SVE path when compile with gcc10.
> 20.11 user will be able to use hns3 SVE path. 
> Implementation 'a' should be fine for both 20.11 and 21.08.
> 
>>
>> If we reuse the CC_SVE_ACLE_SUPPORT macro, there maybe problem when
>> backporting:
>> a. In 21.08 we could depend on CC_SVE_ACLE_SUPPORT, so it will be:
>>     if dpdk_conf.get('CC_SVE_ACLE_SUPPORT')
>>         sources += files('hns3_rxtx_vec_sve.c')
>>     elif cc.has_argument('-march=armv8.2-a+sve') and
>> cc.check_header('arm_sve.h')
> gcc10 user will go into this branch, and SVE path will be included.
> It is identical in 'a' and 'b'.
> 
>>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
>>         ...
>> b. But for backport to 20.11, we should use another impl:
>>     if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
>> cc.check_header('arm_sve.h')
> 'if' clause in implementation 'a' will have the same behavior as this one in 20.11.
>  Both of the checks will be false. 
> 'CC_SVE_ACLE_SUPPORT' is not defined in 20.11 -> result in false.
> No machine_args have sve enabled in 20.11 -> result in false.
> So I think there is a chance we can use a single macro.
> 
>>         cflags += ['-DCC_SVE_ACLE_SUPPORT']
>>         sources += files('hns3_rxtx_vec_sve.c')
>>     elif cc.has_argument('-march=armv8.2-a+sve') and
>> cc.check_header('arm_sve.h')
>>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
>>         ...
>> As you see, the above two are not unified.
>>
>> So here I think use the CC_SVE_SUPPORT is appropriate.
>>
>> @Ferruh  what's your opinion ?
>>
>>>>         sources += files('hns3_rxtx_vec_sve.c')
>>>>     elif cc.has_argument('-march=armv8.2-a+sve') and
>>>> cc.check_header('arm_sve.h')
>>>>         sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
>>> This is fine. Macro name is consistent.
>>>
>>>>         foreach flag: cflags
>>>>             # filterout -march -mcpu -mtune
>>>>             if not (flag.startswith('-march=') or
>>>> flag.startswith('-mcpu=') or
>>>> flag.startswith('-mtune='))
>>>>                 sve_cflags += flag
>>>>             endif
>>>>         endforeach
>>>> but this way may introduce coupling, I think.
>>>>
>>>>>>
>>>>>>> [1]
>>>>>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-
>> git-
>>>>>>> se
>>>>>>> nd
>>>>>>> -email-fengchengwen@huawei.com/
>>>>>>>
>>>>>>>>          sources += files('hns3_rxtx_vec_sve.c')
>>>>>>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
>>>>>>>> cc.check_header('arm_sve.h')
>>>>>>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>>>>>>>> +        foreach flag: cflags
>>>>>>>> +            # filterout -march -mcpu -mtune
>>>>>>>> +            if not (flag.startswith('-march=') or
>>>>>>>> + flag.startswith('-mcpu=') or
>>>>>>>> flag.startswith('-mtune='))
>>>>>>>> +                sve_cflags += flag
>>>>>>>> +            endif
>>>>>>>> +        endforeach
>>>>>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>>>>>>> +                        'hns3_rxtx_vec_sve.c',
>>>>>>>> +                        dependencies: [static_rte_ethdev],
>>>>>>>> +                        include_directories: includes,
>>>>>>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>>>>>>>> +        objs +=
>>>>>>>> + hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>>>>>>      endif
>>>>>>>>  endif
>>>>>>>> --
>>>>>>>> 2.8.1
>>>>>>>
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>
>>>
> 

[dpdk-dev] [PATCH v7 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v7:
* reuse CC_SVE_ACLE_SUPPORT macro in 2/2 patch
v6:
* fix compile error with gcc8.3 and thunder2 of 2/2 patch
v5:
* make sure 'march_feature' parsed depend on 'march_base'
* only the kunpeng930 use the new option
v4:
* fix compile option combine problem of 1/2 patch
v3:
* fix checkpatch error of 1/2 patch
* modify comments of 1/2 patch
v2:
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select most suitable -march for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 36 ++++++++++++++++++++++++++++++++++--
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
 3 files changed, 54 insertions(+), 4 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v7 1/2] config/arm: select most suitable -march for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature': ['crypto', 'sve']
Note: If user defined 'march_feature', it also needs to define a valid
'march_base' because 'march_feature' depends on 'march_base' when
checking validity.
3. Select the most suitable march+feature combination based on
'march_base' and 'march_feature' tuples.
4. Use the selected march+feature combination as the default
machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..044812f 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -158,7 +158,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base': ['-march=armv8.2-a'],
+            'march_feature': ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +451,33 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the most suitable march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        tmp_machine_march = ''
+        march_valid = false
+        foreach march: part_number_config['march_base']
+            if cc.has_argument(march)
+                tmp_machine_march = march # Set the higher supported march as possible
+                march_valid = true
+            endif
+        endforeach
+        # select feature only when march valid
+        if march_valid and part_number_config.has_key('march_feature')
+            foreach feature: part_number_config['march_feature']
+                tmp_feature = tmp_machine_march + '+' + feature
+                if cc.has_argument(tmp_feature)
+                    tmp_machine_march = tmp_feature # Set the more supported feature as possible
+                endif
+            endforeach
+        endif
+        if march_valid
+            machine_march = [tmp_machine_march]
+        endif
+    endif
+
     # apply supported machine args
-    machine_args = [] # Clear previous machine args
+    machine_args = machine_march # Init with machine march which set above
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

[dpdk-dev] [PATCH v7 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

Note: this patch also fixes compile error with gcc8.3 +
'-march=armv8.a+sve', the error is arm_sve.h no such file or directory.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build       |  5 +++++
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 044812f..fe1ce2c 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -506,3 +506,8 @@ if cc.get_define('__ARM_FEATURE_CRYPTO', args: machine_args) != ''
     compile_time_cpuflags += ['RTE_CPUFLAG_AES', 'RTE_CPUFLAG_PMULL',
     'RTE_CPUFLAG_SHA1', 'RTE_CPUFLAG_SHA2']
 endif
+
+if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
+        cc.check_header('arm_sve.h'))
+    dpdk_conf.set('CC_SVE_ACLE_SUPPORT', 1)
+endif
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..9b2f082 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_ACLE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..aabcf23 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,25 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
-    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
+    if dpdk_conf.has('CC_SVE_ACLE_SUPPORT')
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
+        cflags += ['-DCC_SVE_ACLE_SUPPORT=1']
+        sve_cflags = []
+        foreach flag: cflags
+            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
+                sve_cflags += flag
+            endif
+        endforeach
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

[dpdk-dev] [PATCH v8 0/2] bugfix for Kunpeng SVE compile

[Chengwen Feng]

This patch set contains two bugfixes for Kunpeng SVE compile.

---
v8:
* rm config/arm/meson.build from 2/2 patch which add in v7
v7:
* reuse CC_SVE_ACLE_SUPPORT macro in 2/2 patch
v6:
* fix compile error with gcc8.3 and thunder2 of 2/2 patch
v5:
* make sure 'march_feature' parsed depend on 'march_base'
* only the kunpeng930 use the new option
v4:
* fix compile option combine problem of 1/2 patch
v3:
* fix checkpatch error of 1/2 patch
* modify comments of 1/2 patch
v2:
* support select best -march parameter for kunpeng soc

Chengwen Feng (2):
  config/arm: select most suitable -march for kunpeng soc
  net/hns3: refactor SVE code compile method

 config/arm/meson.build       | 31 +++++++++++++++++++++++++++++--
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
 3 files changed, 49 insertions(+), 4 deletions(-)

-- 
2.8.1

[dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

[Chengwen Feng]

Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
but some compiler doesn't recognize the march because it doesn't
support sve.

To solve this bug we use the following scheme:
1. Define 'march_base' tuple which defines support march, it should
arrange from lower to higher.
e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a']
2. Define 'march_feature' tuple which defines support feature.
e.g. 'march_feature': ['crypto', 'sve']
Note: If user defined 'march_feature', it also needs to define a valid
'march_base' because 'march_feature' depends on 'march_base' when
checking validity.
3. Select the most suitable march+feature combination based on
'march_base' and 'march_feature' tuples.
4. Use the selected march+feature combination as the default
machine_args.

Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 config/arm/meson.build | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 3f34ec9..044812f 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -158,7 +158,9 @@ implementer_hisilicon = {
             ]
         },
         '0xd02': {
-            'machine_args': ['-march=armv8.2-a+crypto+sve'],
+            'march_base': ['-march=armv8.2-a'],
+            'march_feature': ['crypto', 'sve'],
+            'machine_args': [],
             'flags': [
                 ['RTE_MACHINE', '"Kunpeng 930"'],
                 ['RTE_ARM_FEATURE_ATOMICS', true],
@@ -449,8 +451,33 @@ else
     # add/overwrite flags in the proper order
     dpdk_flags = flags_common + implementer_config['flags'] + part_number_config.get('flags', []) + soc_flags
 
+    # select the most suitable march+feature combination
+    machine_march = []
+    if part_number_config.has_key('march_base')
+        tmp_machine_march = ''
+        march_valid = false
+        foreach march: part_number_config['march_base']
+            if cc.has_argument(march)
+                tmp_machine_march = march # Set the higher supported march as possible
+                march_valid = true
+            endif
+        endforeach
+        # select feature only when march valid
+        if march_valid and part_number_config.has_key('march_feature')
+            foreach feature: part_number_config['march_feature']
+                tmp_feature = tmp_machine_march + '+' + feature
+                if cc.has_argument(tmp_feature)
+                    tmp_machine_march = tmp_feature # Set the more supported feature as possible
+                endif
+            endforeach
+        endif
+        if march_valid
+            machine_march = [tmp_machine_march]
+        endif
+    endif
+
     # apply supported machine args
-    machine_args = [] # Clear previous machine args
+    machine_args = machine_march # Init with machine march which set above
     foreach flag: part_number_config['machine_args']
         if cc.has_argument(flag)
             machine_args += flag
-- 
2.8.1

Re: [dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

[Thomas Monjalon]

24/05/2021 15:23, Chengwen Feng:
> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> but some compiler doesn't recognize the march because it doesn't
> support sve.
> 
> To solve this bug we use the following scheme:
> 1. Define 'march_base' tuple which defines support march, it should
> arrange from lower to higher.
> e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a']
> 2. Define 'march_feature' tuple which defines support feature.
> e.g. 'march_feature': ['crypto', 'sve']
> Note: If user defined 'march_feature', it also needs to define a valid
> 'march_base' because 'march_feature' depends on 'march_base' when
> checking validity.
> 3. Select the most suitable march+feature combination based on
> 'march_base' and 'march_feature' tuples.
> 4. Use the selected march+feature combination as the default
> machine_args.
> 
> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>

This patch is still not accepted.
Arm maintainers, what is missing?
Is it rejected?

Re: [dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

[Honnappa Nagarahalli]

<snip>

> 
> 24/05/2021 15:23, Chengwen Feng:
> > Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> > but some compiler doesn't recognize the march because it doesn't
> > support sve.
> >
> > To solve this bug we use the following scheme:
> > 1. Define 'march_base' tuple which defines support march, it should
> > arrange from lower to higher.
> > e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a'] 2. Define
> > 'march_feature' tuple which defines support feature.
> > e.g. 'march_feature': ['crypto', 'sve']
> > Note: If user defined 'march_feature', it also needs to define a valid
> > 'march_base' because 'march_feature' depends on 'march_base' when
> > checking validity.
> > 3. Select the most suitable march+feature combination based on
> > 'march_base' and 'march_feature' tuples.
> > 4. Use the selected march+feature combination as the default
> > machine_args.
> >
> > Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> >
> > Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> 
> This patch is still not accepted.
> Arm maintainers, what is missing?
> Is it rejected?
Juraj is working on a more generalized solution. Not sure how it will turn out. It would be good to wait.

> 
> 
> 

Re: [dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

[fengchengwen]

Hi, Thomas

Another patch '[dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method'
has nothing to do with this patch (they're just in the same patchset) and has been
reviewed by ARM guys.

So please review it, thanks.


On 2021/6/18 7:33, Honnappa Nagarahalli wrote:
> <snip>
> 
>>
>> 24/05/2021 15:23, Chengwen Feng:
>>> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
>>> but some compiler doesn't recognize the march because it doesn't
>>> support sve.
>>>
>>> To solve this bug we use the following scheme:
>>> 1. Define 'march_base' tuple which defines support march, it should
>>> arrange from lower to higher.
>>> e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a'] 2. Define
>>> 'march_feature' tuple which defines support feature.
>>> e.g. 'march_feature': ['crypto', 'sve']
>>> Note: If user defined 'march_feature', it also needs to define a valid
>>> 'march_base' because 'march_feature' depends on 'march_base' when
>>> checking validity.
>>> 3. Select the most suitable march+feature combination based on
>>> 'march_base' and 'march_feature' tuples.
>>> 4. Use the selected march+feature combination as the default
>>> machine_args.
>>>
>>> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
>>>
>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>
>> This patch is still not accepted.
>> Arm maintainers, what is missing?
>> Is it rejected?
> Juraj is working on a more generalized solution. Not sure how it will turn out. It would be good to wait.
> 
>>
>>
>>
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

[Thomas Monjalon]

21/06/2021 02:52, fengchengwen:
> Hi, Thomas
> 
> Another patch '[dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method'
> has nothing to do with this patch (they're just in the same patchset) and has been
> reviewed by ARM guys.

If they are unrelated, why are they in the same patchset?

> So please review it, thanks.

Re: [dpdk-dev] [PATCH v8 1/2] config/arm: select most suitable -march for kunpeng soc

[fengchengwen]

On 2021/6/23 16:08, Thomas Monjalon wrote:
> 21/06/2021 02:52, fengchengwen:
>> Hi, Thomas
>>
>> Another patch '[dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method'
>> has nothing to do with this patch (they're just in the same patchset) and has been
>> reviewed by ARM guys.
> 
> If they are unrelated, why are they in the same patchset?

They're all SVE-related issues, so put in the same patchset.

I will send one new patchset include following two patch because they both ref
'RTE_HAS_SVE_ACLE' which you mention previous thread.
  build: fix SVE compile error with gcc8.3
  net/hns3: refactor SVE code compile method

> 
>> So please review it, thanks.
> 
> 
> 
> 
> 
> 
> .
> 

[dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method

[Chengwen Feng]

Currently, the SVE code is compiled only when -march supports SVE
(e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
approach.

The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.

Note: this patch also fixes compile error with gcc8.3 +
'-march=armv8.a+sve', the error is arm_sve.h no such file or directory.

[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html

Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: stable@dpdk.org

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 drivers/net/hns3/hns3_rxtx.c |  2 +-
 drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 1d7a769..9b2f082 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
 static bool
 hns3_get_sve_support(void)
 {
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_ACLE_SUPPORT)
 	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
 		return false;
 	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
index 53c7df7..aabcf23 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,25 @@ deps += ['hash']
 
 if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
     sources += files('hns3_rxtx_vec.c')
-    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+
+    # compile SVE when:
+    # a. support SVE in minimum instruction set baseline
+    # b. it's not minimum instruction set, but compiler support
+    if dpdk_conf.has('CC_SVE_ACLE_SUPPORT')
         sources += files('hns3_rxtx_vec_sve.c')
+    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
+        cflags += ['-DCC_SVE_ACLE_SUPPORT=1']
+        sve_cflags = []
+        foreach flag: cflags
+            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
+                sve_cflags += flag
+            endif
+        endforeach
+        hns3_sve_lib = static_library('hns3_sve_lib',
+                        'hns3_rxtx_vec_sve.c',
+                        dependencies: [static_rte_ethdev],
+                        include_directories: includes,
+                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
+        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
     endif
 endif
-- 
2.8.1

Re: [dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method

[Ruifeng Wang]

> -----Original Message-----
> From: Chengwen Feng <fengchengwen@huawei.com>
> Sent: Monday, May 24, 2021 9:23 PM
> To: thomas@monjalon.net; ferruh.yigit@intel.com
> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
> bruce.richardson@intel.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
> juraj.linkes@pantheon.tech; nd <nd@arm.com>
> Subject: [PATCH v8 2/2] net/hns3: refactor SVE code compile method
> 
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
> 
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
> 
> Note: this patch also fixes compile error with gcc8.3 + '-march=armv8.a+sve',
> the error is arm_sve.h no such file or directory.
> 
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> 
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  drivers/net/hns3/hns3_rxtx.c |  2 +-
>  drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..9b2f082 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>  static bool
>  hns3_get_sve_support(void)
>  {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_ACLE_SUPPORT)
>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>  		return false;
>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..aabcf23 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,25 @@ deps += ['hash']
> 
>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
> +    if dpdk_conf.has('CC_SVE_ACLE_SUPPORT')
>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
> +        cflags += ['-DCC_SVE_ACLE_SUPPORT=1']
> +        sve_cflags = []
> +        foreach flag: cflags
> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
> flag.startswith('-mtune='))
> +                sve_cflags += flag
> +            endif
> +        endforeach
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
>  endif
> --
> 2.8.1

Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>

Re: [dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method

[Fengchengwen]

Hi, Ferruh

    Could you review this patch ? Thanks


From:Ruifeng Wang <Ruifeng.Wang@arm.com>
To:Fengchengwen <fengchengwen@huawei.com>;Thomas Monjalon <thomas@monjalon.net>;ferruh.yigit <ferruh.yigit@intel.com>
Cc:dev <dev@dpdk.org>;Jerin Jacob <jerinj@marvell.com>;viktorin <viktorin@rehivetech.com>;Richardson, Bruce <bruce.richardson@intel.com>;Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;jerinjacobk <jerinjacobk@gmail.com>;Juraj Linkeš <juraj.linkes@pantheon.tech>;nd <nd@arm.com>;nd <nd@arm.com>
Date:2021-05-25 14:04:52
Subject:RE: [PATCH v8 2/2] net/hns3: refactor SVE code compile method

> -----Original Message-----
> From: Chengwen Feng < fengchengwen@huawei.com<mailto:fengchengwen@huawei.com>>
> Sent: Monday, May 24, 2021 9:23 PM
> To: thomas@monjalon.net<mailto:thomas@monjalon.net>; ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>; jerinj@marvell.com<mailto:jerinj@marvell.com>; Ruifeng Wang
> < Ruifeng.Wang@arm.com<mailto:Ruifeng.Wang@arm.com>>; viktorin@rehivetech.com<mailto:viktorin@rehivetech.com>;
> bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>; Honnappa Nagarahalli
> < Honnappa.Nagarahalli@arm.com<mailto:Honnappa.Nagarahalli@arm.com>>; jerinjacobk@gmail.com<mailto:jerinjacobk@gmail.com>;
> juraj.linkes@pantheon.tech<mailto:juraj.linkes@pantheon.tech>; nd < nd@arm.com<mailto:nd@arm.com>>
> Subject: [PATCH v8 2/2] net/hns3: refactor SVE code compile method
>
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
>
> Note: this patch also fixes compile error with gcc8.3 + '-march=armv8.a+sve',
> the error is arm_sve.h no such file or directory.
>
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: stable@dpdk.org<mailto:stable@dpdk.org>
>
> Signed-off-by: Chengwen Feng < fengchengwen@huawei.com<mailto:fengchengwen@huawei.com>>
> ---
> drivers/net/hns3/hns3_rxtx.c | 2 +-
> drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..9b2f082 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> static bool
> hns3_get_sve_support(void)
> {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_ACLE_SUPPORT)
>        if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>                return false;
>        if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..aabcf23 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,25 @@ deps += ['hash']
>
> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>      sources += files('hns3_rxtx_vec.c')
> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +
> +    # compile SVE when:
> +    # a. support SVE in minimum instruction set baseline
> +    # b. it's not minimum instruction set, but compiler support
> +    if dpdk_conf.has('CC_SVE_ACLE_SUPPORT')
>          sources += files('hns3_rxtx_vec_sve.c')
> +    elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
> +        cflags += ['-DCC_SVE_ACLE_SUPPORT=1']
> +        sve_cflags = []
> +        foreach flag: cflags
> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
> flag.startswith('-mtune='))
> +                sve_cflags += flag
> +            endif
> +        endforeach
> +        hns3_sve_lib = static_library('hns3_sve_lib',
> +                        'hns3_rxtx_vec_sve.c',
> +                        dependencies: [static_rte_ethdev],
> +                        include_directories: includes,
> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>      endif
> endif
> --
> 2.8.1

Reviewed-by: Ruifeng Wang < ruifeng.wang@arm.com<mailto:ruifeng.wang@arm.com>>

Re: [dpdk-dev] [PATCH v8 2/2] net/hns3: refactor SVE code compile method

[fengchengwen]

Friendly ping


On 2021/5/27 15:07, Fengchengwen wrote:
> 
> Hi, Ferruh
> 
>     Could you review this patch ? Thanks
> 
> 
> From:Ruifeng Wang <Ruifeng.Wang@arm.com>
> To:Fengchengwen <fengchengwen@huawei.com>;Thomas Monjalon <thomas@monjalon.net>;ferruh.yigit <ferruh.yigit@intel.com>
> Cc:dev <dev@dpdk.org>;Jerin Jacob <jerinj@marvell.com>;viktorin <viktorin@rehivetech.com>;Richardson, Bruce <bruce.richardson@intel.com>;Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;jerinjacobk <jerinjacobk@gmail.com>;Juraj Linkeš <juraj.linkes@pantheon.tech>;nd <nd@arm.com>;nd <nd@arm.com>
> Date:2021-05-25 14:04:52
> Subject:RE: [PATCH v8 2/2] net/hns3: refactor SVE code compile method
> 
>> -----Original Message-----
>> From: Chengwen Feng < fengchengwen@huawei.com<mailto:fengchengwen@huawei.com>>
>> Sent: Monday, May 24, 2021 9:23 PM
>> To: thomas@monjalon.net<mailto:thomas@monjalon.net>; ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org<mailto:dev@dpdk.org>; jerinj@marvell.com<mailto:jerinj@marvell.com>; Ruifeng Wang
>> < Ruifeng.Wang@arm.com<mailto:Ruifeng.Wang@arm.com>>; viktorin@rehivetech.com<mailto:viktorin@rehivetech.com>;
>> bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>; Honnappa Nagarahalli
>> < Honnappa.Nagarahalli@arm.com<mailto:Honnappa.Nagarahalli@arm.com>>; jerinjacobk@gmail.com<mailto:jerinjacobk@gmail.com>;
>> juraj.linkes@pantheon.tech<mailto:juraj.linkes@pantheon.tech>; nd < nd@arm.com<mailto:nd@arm.com>>
>> Subject: [PATCH v8 2/2] net/hns3: refactor SVE code compile method
>>
>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> Note: this patch also fixes compile error with gcc8.3 + '-march=armv8.a+sve',
>> the error is arm_sve.h no such file or directory.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: stable@dpdk.org<mailto:stable@dpdk.org>
>>
>> Signed-off-by: Chengwen Feng < fengchengwen@huawei.com<mailto:fengchengwen@huawei.com>>
>> ---
>> drivers/net/hns3/hns3_rxtx.c | 2 +-
>> drivers/net/hns3/meson.build | 20 +++++++++++++++++++-
>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>> index 1d7a769..9b2f082 100644
>> --- a/drivers/net/hns3/hns3_rxtx.c
>> +++ b/drivers/net/hns3/hns3_rxtx.c
>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>> static bool
>> hns3_get_sve_support(void)
>> {
>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>> +#if defined(CC_SVE_ACLE_SUPPORT)
>>        if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>                return false;
>>        if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>> index 53c7df7..aabcf23 100644
>> --- a/drivers/net/hns3/meson.build
>> +++ b/drivers/net/hns3/meson.build
>> @@ -35,7 +35,25 @@ deps += ['hash']
>>
>> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>      sources += files('hns3_rxtx_vec.c')
>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>> +
>> +    # compile SVE when:
>> +    # a. support SVE in minimum instruction set baseline
>> +    # b. it's not minimum instruction set, but compiler support
>> +    if dpdk_conf.has('CC_SVE_ACLE_SUPPORT')
>>          sources += files('hns3_rxtx_vec_sve.c')
>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
>> cc.check_header('arm_sve.h')
>> +        cflags += ['-DCC_SVE_ACLE_SUPPORT=1']
>> +        sve_cflags = []
>> +        foreach flag: cflags
>> +            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
>> flag.startswith('-mtune='))
>> +                sve_cflags += flag
>> +            endif
>> +        endforeach
>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>> +                        'hns3_rxtx_vec_sve.c',
>> +                        dependencies: [static_rte_ethdev],
>> +                        include_directories: includes,
>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>      endif
>> endif
>> --
>> 2.8.1
> 
> Reviewed-by: Ruifeng Wang < ruifeng.wang@arm.com<mailto:ruifeng.wang@arm.com>>
>