patches for DPDK stable branches
 help / color / mirror / Atom feed
* [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
@ 2021-02-19 10:57 luca.boccassi
  2021-02-19 11:06 ` Juraj Linkeš
  0 siblings, 1 reply; 15+ messages in thread
From: luca.boccassi @ 2021-02-19 10:57 UTC (permalink / raw)
  To: stable; +Cc: juraj.linkes, jerinj, ruifeng.wang, david.marchand

From: Juraj Linkeš <juraj.linkes@pantheon.tech>

[ backported from upstream commit 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]

There are compiler issues when building with -mcpu=native with popular
compilers, such as GCC-8.4:
In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
                 from ../lib/librte_net/net_crc_neon.c:10:
../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
/usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
inlining failed in call to always_inline ‘vmull_p64’:
target specific option mismatch
 vmull_p64 (poly64_t a, poly64_t b)
../lib/librte_net/net_crc_neon.c:50:20: note: called from here
  uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
    vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
    vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));

and clang:
gcc -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
clang-9 -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
<no output> # no clang support

Fix this by always specifying the proper machine args and never using
the native flags.

Fixes: 78ac8eac7e8a ("config/arm: use native machine build arguments")

Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
---
This is a crude backport, but it fixes the build for arm64. It's a
release blocker for 20.11.1, so I would appreciate a quick review.
Thanks!

 config/arm/meson.build | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 42b4e43c74..8beae4a3f9 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -5,7 +5,6 @@
 # for checking defines we need to use the correct compiler flags
 march_opt = '-march=@0@'.format(machine)
 
-arm_force_native_march = false
 arm_force_default_march = (machine == 'default')
 
 flags_common_default = [
@@ -92,7 +91,6 @@ flags_n1generic_extra = [
 
 machine_args_generic = [
 	['default', ['-march=armv8-a+crc', '-moutline-atomics']],
-	['native', ['-march=native']],
 	['0xd03', ['-mcpu=cortex-a53']],
 	['0xd04', ['-mcpu=cortex-a35']],
 	['0xd07', ['-mcpu=cortex-a57']],
@@ -104,7 +102,6 @@ machine_args_generic = [
 
 machine_args_cavium = [
 	['default', ['-march=armv8-a+crc+crypto','-mcpu=thunderx']],
-	['native', ['-march=native']],
 	['0xa1', ['-mcpu=thunderxt88'], flags_thunderx_extra],
 	['0xa2', ['-mcpu=thunderxt81'], flags_thunderx_extra],
 	['0xa3', ['-mcpu=thunderxt83'], flags_thunderx_extra],
@@ -112,8 +109,7 @@ machine_args_cavium = [
 	['0xb2', ['-march=armv8.2-a+crc+crypto+lse','-mcpu=octeontx2'], flags_octeontx2_extra]]
 
 machine_args_emag = [
-	['default', ['-march=armv8-a+crc+crypto', '-mtune=emag']],
-	['native', ['-march=native']]]
+	['default', ['-march=armv8-a+crc+crypto', '-mtune=emag']]]
 
 ## Arm implementer ID (ARM DDI 0487C.a, Section G7.2.106, Page G7-5321)
 impl_generic = ['Generic armv8', flags_generic, machine_args_generic]
@@ -167,9 +163,6 @@ else
 			cmd_output = cmd_generic
 		endif
 		impl_pn = cmd_output[3]
-		if arm_force_native_march == true
-			impl_pn = 'native'
-		endif
 	else
 		impl_id = meson.get_cross_property('implementor_id', 'generic')
 		impl_pn = meson.get_cross_property('implementor_pn', 'default')
-- 
2.29.2


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-19 10:57 [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args luca.boccassi
@ 2021-02-19 11:06 ` Juraj Linkeš
  2021-02-19 11:33   ` Luca Boccassi
  0 siblings, 1 reply; 15+ messages in thread
From: Juraj Linkeš @ 2021-02-19 11:06 UTC (permalink / raw)
  To: luca.boccassi, stable; +Cc: jerinj, ruifeng.wang, david.marchand



> -----Original Message-----
> From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> Sent: Friday, February 19, 2021 11:58 AM
> To: stable@dpdk.org
> Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>; jerinj@marvell.com;
> ruifeng.wang@arm.com; david.marchand@redhat.com
> Subject: [PATCH 20.11] config/arm: replace native machine args
> 
> From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> 
> [ backported from upstream commit
> 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> 
> There are compiler issues when building with -mcpu=native with popular
> compilers, such as GCC-8.4:
> In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
>                  from ../lib/librte_net/net_crc_neon.c:10:
> ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> inlining failed in call to always_inline ‘vmull_p64’:
> target specific option mismatch
>  vmull_p64 (poly64_t a, poly64_t b)
> ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
>   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
>     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
>     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> 
> and clang:
> gcc -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
> clang-9 -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
> <no output> # no clang support
> 
> Fix this by always specifying the proper machine args and never using the native
> flags.
> 
> Fixes: 78ac8eac7e8a ("config/arm: use native machine build arguments")
> 
> Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> ---
> This is a crude backport, but it fixes the build for arm64. It's a release blocker for
> 20.11.1, so I would appreciate a quick review.
> Thanks!

What does this fix? With or without the below change, the native machine args are not used. The patch shoudn't actually change the configuration of the build at all, so I'm a bit confused.

> 
>  config/arm/meson.build | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> 42b4e43c74..8beae4a3f9 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -5,7 +5,6 @@
>  # for checking defines we need to use the correct compiler flags  march_opt = '-
> march=@0@'.format(machine)
> 
> -arm_force_native_march = false
>  arm_force_default_march = (machine == 'default')
> 
>  flags_common_default = [
> @@ -92,7 +91,6 @@ flags_n1generic_extra = [
> 
>  machine_args_generic = [
>  	['default', ['-march=armv8-a+crc', '-moutline-atomics']],
> -	['native', ['-march=native']],
>  	['0xd03', ['-mcpu=cortex-a53']],
>  	['0xd04', ['-mcpu=cortex-a35']],
>  	['0xd07', ['-mcpu=cortex-a57']],
> @@ -104,7 +102,6 @@ machine_args_generic = [
> 
>  machine_args_cavium = [
>  	['default', ['-march=armv8-a+crc+crypto','-mcpu=thunderx']],
> -	['native', ['-march=native']],
>  	['0xa1', ['-mcpu=thunderxt88'], flags_thunderx_extra],
>  	['0xa2', ['-mcpu=thunderxt81'], flags_thunderx_extra],
>  	['0xa3', ['-mcpu=thunderxt83'], flags_thunderx_extra], @@ -112,8
> +109,7 @@ machine_args_cavium = [
>  	['0xb2', ['-march=armv8.2-a+crc+crypto+lse','-mcpu=octeontx2'],
> flags_octeontx2_extra]]
> 
>  machine_args_emag = [
> -	['default', ['-march=armv8-a+crc+crypto', '-mtune=emag']],
> -	['native', ['-march=native']]]
> +	['default', ['-march=armv8-a+crc+crypto', '-mtune=emag']]]
> 
>  ## Arm implementer ID (ARM DDI 0487C.a, Section G7.2.106, Page G7-5321)
> impl_generic = ['Generic armv8', flags_generic, machine_args_generic] @@ -
> 167,9 +163,6 @@ else
>  			cmd_output = cmd_generic
>  		endif
>  		impl_pn = cmd_output[3]
> -		if arm_force_native_march == true
> -			impl_pn = 'native'
> -		endif
>  	else
>  		impl_id = meson.get_cross_property('implementor_id',
> 'generic')
>  		impl_pn = meson.get_cross_property('implementor_pn',
> 'default')
> --
> 2.29.2
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-19 11:06 ` Juraj Linkeš
@ 2021-02-19 11:33   ` Luca Boccassi
  2021-02-19 12:10     ` Juraj Linkeš
  0 siblings, 1 reply; 15+ messages in thread
From: Luca Boccassi @ 2021-02-19 11:33 UTC (permalink / raw)
  To: Juraj Linkeš, stable; +Cc: jerinj, ruifeng.wang, david.marchand

On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > -----Original Message-----
> > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > Sent: Friday, February 19, 2021 11:58 AM
> > To: stable@dpdk.org
> > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>; jerinj@marvell.com;
> > ruifeng.wang@arm.com; david.marchand@redhat.com
> > Subject: [PATCH 20.11] config/arm: replace native machine args
> > 
> > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > 
> > [ backported from upstream commit
> > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > 
> > There are compiler issues when building with -mcpu=native with popular
> > compilers, such as GCC-8.4:
> > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> >                  from ../lib/librte_net/net_crc_neon.c:10:
> > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > inlining failed in call to always_inline ‘vmull_p64’:
> > target specific option mismatch
> >  vmull_p64 (poly64_t a, poly64_t b)
> > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > 
> > and clang:
> > gcc -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
> > clang-9 -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
> > <no output> # no clang support
> > 
> > Fix this by always specifying the proper machine args and never using the native
> > flags.
> > 
> > Fixes: 78ac8eac7e8a ("config/arm: use native machine build arguments")
> > 
> > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > ---
> > This is a crude backport, but it fixes the build for arm64. It's a release blocker for
> > 20.11.1, so I would appreciate a quick review.
> > Thanks!
> 
> What does this fix? With or without the below change, the native machine args are not used. The patch shoudn't actually change the configuration of the build at all, so I'm a bit confused.

It fixes the build on some build workers with thunderx hardware -
without this I get failures like:

arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
'vmull_p64': target specific option mismatch

-- 
Kind regards,
Luca Boccassi

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-19 11:33   ` Luca Boccassi
@ 2021-02-19 12:10     ` Juraj Linkeš
  2021-02-19 13:04       ` Luca Boccassi
  2021-02-20  3:42       ` Ruifeng Wang
  0 siblings, 2 replies; 15+ messages in thread
From: Juraj Linkeš @ 2021-02-19 12:10 UTC (permalink / raw)
  To: Luca Boccassi, stable; +Cc: jerinj, ruifeng.wang, david.marchand



> -----Original Message-----
> From: Luca Boccassi <bluca@debian.org>
> Sent: Friday, February 19, 2021 12:33 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> Cc: jerinj@marvell.com; ruifeng.wang@arm.com; david.marchand@redhat.com
> Subject: Re: [PATCH 20.11] config/arm: replace native machine args
> 
> On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > -----Original Message-----
> > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > Sent: Friday, February 19, 2021 11:58 AM
> > > To: stable@dpdk.org
> > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>; jerinj@marvell.com;
> > > ruifeng.wang@arm.com; david.marchand@redhat.com
> > > Subject: [PATCH 20.11] config/arm: replace native machine args
> > >
> > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > >
> > > [ backported from upstream commit
> > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > >
> > > There are compiler issues when building with -mcpu=native with
> > > popular compilers, such as GCC-8.4:
> > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > inlining failed in call to always_inline ‘vmull_p64’:
> > > target specific option mismatch
> > >  vmull_p64 (poly64_t a, poly64_t b)
> > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > >
> > > and clang:
> > > gcc -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
> > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > >
> > > Fix this by always specifying the proper machine args and never
> > > using the native flags.
> > >
> > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > arguments")
> > >
> > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > ---
> > > This is a crude backport, but it fixes the build for arm64. It's a
> > > release blocker for 20.11.1, so I would appreciate a quick review.
> > > Thanks!
> >
> > What does this fix? With or without the below change, the native machine
> args are not used. The patch shoudn't actually change the configuration of the
> build at all, so I'm a bit confused.
> 
> It fixes the build on some build workers with thunderx hardware - without this I
> get failures like:
> 
> arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> 'vmull_p64': target specific option mismatch
> 

I tried the patch and I'm seeing the same errors on a ThunderX server (with and without the patch). Is this actually the right patch?

One of the four failures looks like this:
In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
                 from ../lib/librte_net/net_crc_neon.c:10:
../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
/usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error: inlining failed in call to always_inline 'vmull_p64': target specific option mismatch
 vmull_p64 (poly64_t a, poly64_t b)
 ^~~~~~~~~
../lib/librte_net/net_crc_neon.c:50:20: note: called from here
  uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ruifeng, any ideas on how to fix this?

> --
> Kind regards,
> Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-19 12:10     ` Juraj Linkeš
@ 2021-02-19 13:04       ` Luca Boccassi
  2021-02-24 12:51         ` Juraj Linkeš
  2021-02-20  3:42       ` Ruifeng Wang
  1 sibling, 1 reply; 15+ messages in thread
From: Luca Boccassi @ 2021-02-19 13:04 UTC (permalink / raw)
  To: Juraj Linkeš, stable; +Cc: jerinj, ruifeng.wang, david.marchand

On Fri, 2021-02-19 at 12:10 +0000, Juraj Linkeš wrote:
> > -----Original Message-----
> > From: Luca Boccassi <bluca@debian.org>
> > Sent: Friday, February 19, 2021 12:33 PM
> > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > Cc: jerinj@marvell.com; ruifeng.wang@arm.com; david.marchand@redhat.com
> > Subject: Re: [PATCH 20.11] config/arm: replace native machine args
> > 
> > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > -----Original Message-----
> > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > To: stable@dpdk.org
> > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>; jerinj@marvell.com;
> > > > ruifeng.wang@arm.com; david.marchand@redhat.com
> > > > Subject: [PATCH 20.11] config/arm: replace native machine args
> > > > 
> > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > 
> > > > [ backported from upstream commit
> > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > 
> > > > There are compiler issues when building with -mcpu=native with
> > > > popular compilers, such as GCC-8.4:
> > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > target specific option mismatch
> > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > 
> > > > and clang:
> > > > gcc -E -dM -mcpu="native" - < /dev/null | grep __ARM_FEATURE_ATOMICS
> > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > 
> > > > Fix this by always specifying the proper machine args and never
> > > > using the native flags.
> > > > 
> > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > arguments")
> > > > 
> > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > ---
> > > > This is a crude backport, but it fixes the build for arm64. It's a
> > > > release blocker for 20.11.1, so I would appreciate a quick review.
> > > > Thanks!
> > > 
> > > What does this fix? With or without the below change, the native machine
> > args are not used. The patch shoudn't actually change the configuration of the
> > build at all, so I'm a bit confused.
> > 
> > It fixes the build on some build workers with thunderx hardware - without this I
> > get failures like:
> > 
> > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > 'vmull_p64': target specific option mismatch
> > 
> 
> I tried the patch and I'm seeing the same errors on a ThunderX server (with and without the patch). Is this actually the right patch?
> 
> One of the four failures looks like this:
> In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
>                  from ../lib/librte_net/net_crc_neon.c:10:
> ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error: inlining failed in call to always_inline 'vmull_p64': target specific option mismatch
>  vmull_p64 (poly64_t a, poly64_t b)
>  ^~~~~~~~~
> ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
>   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
>                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Ruifeng, any ideas on how to fix this?

Strange, I got from 100% repro rate to 0%. Anyway, please send a better
fix is this is not the appropriate one - this is a release blocker for
20.11.1. Thanks!

-- 
Kind regards,
Luca Boccassi

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-19 12:10     ` Juraj Linkeš
  2021-02-19 13:04       ` Luca Boccassi
@ 2021-02-20  3:42       ` Ruifeng Wang
  2021-02-25 12:14         ` Jerin Jacob Kollanukkaran
  1 sibling, 1 reply; 15+ messages in thread
From: Ruifeng Wang @ 2021-02-20  3:42 UTC (permalink / raw)
  To: Juraj Linkeš, Luca Boccassi, stable, jerinj; +Cc: david.marchand, nd

> -----Original Message-----
> From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Sent: Friday, February 19, 2021 8:10 PM
> To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> david.marchand@redhat.com
> Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> 
> 
> 
> > -----Original Message-----
> > From: Luca Boccassi <bluca@debian.org>
> > Sent: Friday, February 19, 2021 12:33 PM
> > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > david.marchand@redhat.com
> > Subject: Re: [PATCH 20.11] config/arm: replace native machine args
> >
> > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > -----Original Message-----
> > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > To: stable@dpdk.org
> > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>; jerinj@marvell.com;
> > > > ruifeng.wang@arm.com; david.marchand@redhat.com
> > > > Subject: [PATCH 20.11] config/arm: replace native machine args
> > > >
> > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > >
> > > > [ backported from upstream commit
> > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > >
> > > > There are compiler issues when building with -mcpu=native with
> > > > popular compilers, such as GCC-8.4:
> > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > target specific option mismatch
> > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > >
> > > > and clang:
> > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > __ARM_FEATURE_ATOMICS
> > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > >
> > > > Fix this by always specifying the proper machine args and never
> > > > using the native flags.
> > > >
> > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > arguments")
> > > >
> > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > ---
> > > > This is a crude backport, but it fixes the build for arm64. It's a
> > > > release blocker for 20.11.1, so I would appreciate a quick review.
> > > > Thanks!
> > >
> > > What does this fix? With or without the below change, the native
> > > machine
> > args are not used. The patch shoudn't actually change the
> > configuration of the build at all, so I'm a bit confused.
> >
> > It fixes the build on some build workers with thunderx hardware -
> > without this I get failures like:
> >
> > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > 'vmull_p64': target specific option mismatch
> >
> 
> I tried the patch and I'm seeing the same errors on a ThunderX server (with
> and without the patch). Is this actually the right patch?
> 
> One of the four failures looks like this:
> In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
>                  from ../lib/librte_net/net_crc_neon.c:10:
> ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error: inlining
> failed in call to always_inline 'vmull_p64': target specific option mismatch
>  vmull_p64 (poly64_t a, poly64_t b)
>  ^~~~~~~~~
> ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
>   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
>                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Ruifeng, any ideas on how to fix this?

Gcc build on ThunderX platform is broken. Issue can be seen in some CentOS-8 OBS builds.
https://mails.dpdk.org/archives/dev/2020-November/192909.html
I tried tuning compiler flags used, but could not resolve the issue.

Need help from Marvell to look at this.
Hi Jerin, do you have any thoughts on this?
> 
> > --
> > Kind regards,
> > Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-19 13:04       ` Luca Boccassi
@ 2021-02-24 12:51         ` Juraj Linkeš
  0 siblings, 0 replies; 15+ messages in thread
From: Juraj Linkeš @ 2021-02-24 12:51 UTC (permalink / raw)
  To: Luca Boccassi, stable; +Cc: jerinj, ruifeng.wang, david.marchand



> -----Original Message-----
> From: Luca Boccassi <bluca@debian.org>
> Sent: Friday, February 19, 2021 2:04 PM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> Cc: jerinj@marvell.com; ruifeng.wang@arm.com; david.marchand@redhat.com
> Subject: Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine
> args
> 
> On Fri, 2021-02-19 at 12:10 +0000, Juraj Linkeš wrote:
> > > -----Original Message-----
> > > From: Luca Boccassi <bluca@debian.org>
> > > Sent: Friday, February 19, 2021 12:33 PM
> > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > david.marchand@redhat.com
> > > Subject: Re: [PATCH 20.11] config/arm: replace native machine args
> > >
> > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > -----Original Message-----
> > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > To: stable@dpdk.org
> > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > david.marchand@redhat.com
> > > > > Subject: [PATCH 20.11] config/arm: replace native machine args
> > > > >
> > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > >
> > > > > [ backported from upstream commit
> > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > >
> > > > > There are compiler issues when building with -mcpu=native with
> > > > > popular compilers, such as GCC-8.4:
> > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > target specific option mismatch
> > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > >
> > > > > and clang:
> > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > __ARM_FEATURE_ATOMICS
> > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > >
> > > > > Fix this by always specifying the proper machine args and never
> > > > > using the native flags.
> > > > >
> > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > arguments")
> > > > >
> > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > ---
> > > > > This is a crude backport, but it fixes the build for arm64. It's
> > > > > a release blocker for 20.11.1, so I would appreciate a quick review.
> > > > > Thanks!
> > > >
> > > > What does this fix? With or without the below change, the native
> > > > machine
> > > args are not used. The patch shoudn't actually change the
> > > configuration of the build at all, so I'm a bit confused.
> > >
> > > It fixes the build on some build workers with thunderx hardware -
> > > without this I get failures like:
> > >
> > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > 'vmull_p64': target specific option mismatch
> > >
> >
> > I tried the patch and I'm seeing the same errors on a ThunderX server (with and
> without the patch). Is this actually the right patch?
> >
> > One of the four failures looks like this:
> > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> >                  from ../lib/librte_net/net_crc_neon.c:10:
> > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > inlining failed in call to always_inline 'vmull_p64': target specific
> > option mismatch
> >  vmull_p64 (poly64_t a, poly64_t b)
> >  ^~~~~~~~~
> > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Ruifeng, any ideas on how to fix this?
> 
> Strange, I got from 100% repro rate to 0%.

Is this when testing in OBS? If so, the situation could be explained if they're scheduling different hardware for these tests.

Do the machine args meson messages change when you use the patch? E.g.:
Message: Implementer : Cavium
Compiler for C supports arguments -mcpu=thunderxt88: YES
Message: ['-mcpu=thunderxt88']

> Anyway, please send a better fix is
> this is not the appropriate one - this is a release blocker for 20.11.1. Thanks!
> 
> --
> Kind regards,
> Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-20  3:42       ` Ruifeng Wang
@ 2021-02-25 12:14         ` Jerin Jacob Kollanukkaran
  2021-02-25 14:24           ` David Marchand
  2021-03-01  5:40           ` Ruifeng Wang
  0 siblings, 2 replies; 15+ messages in thread
From: Jerin Jacob Kollanukkaran @ 2021-02-25 12:14 UTC (permalink / raw)
  To: Ruifeng Wang, Juraj Linkeš, Luca Boccassi, stable; +Cc: david.marchand, nd

> -----Original Message-----
> From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> Sent: Saturday, February 20, 2021 9:13 AM
> To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>
> Cc: david.marchand@redhat.com; nd <nd@arm.com>
> Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine args
> 
> External Email
> 
> ----------------------------------------------------------------------
> > -----Original Message-----
> > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > Sent: Friday, February 19, 2021 8:10 PM
> > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > david.marchand@redhat.com
> > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> >
> >
> >
> > > -----Original Message-----
> > > From: Luca Boccassi <bluca@debian.org>
> > > Sent: Friday, February 19, 2021 12:33 PM
> > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > david.marchand@redhat.com
> > > Subject: Re: [PATCH 20.11] config/arm: replace native machine args
> > >
> > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > -----Original Message-----
> > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > To: stable@dpdk.org
> > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > david.marchand@redhat.com
> > > > > Subject: [PATCH 20.11] config/arm: replace native machine args
> > > > >
> > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > >
> > > > > [ backported from upstream commit
> > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > >
> > > > > There are compiler issues when building with -mcpu=native with
> > > > > popular compilers, such as GCC-8.4:
> > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > target specific option mismatch
> > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > >
> > > > > and clang:
> > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > __ARM_FEATURE_ATOMICS
> > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > >
> > > > > Fix this by always specifying the proper machine args and never
> > > > > using the native flags.
> > > > >
> > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > arguments")
> > > > >
> > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > ---
> > > > > This is a crude backport, but it fixes the build for arm64. It's
> > > > > a release blocker for 20.11.1, so I would appreciate a quick review.
> > > > > Thanks!
> > > >
> > > > What does this fix? With or without the below change, the native
> > > > machine
> > > args are not used. The patch shoudn't actually change the
> > > configuration of the build at all, so I'm a bit confused.
> > >
> > > It fixes the build on some build workers with thunderx hardware -
> > > without this I get failures like:
> > >
> > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > 'vmull_p64': target specific option mismatch
> > >
> >
> > I tried the patch and I'm seeing the same errors on a ThunderX server
> > (with and without the patch). Is this actually the right patch?
> >
> > One of the four failures looks like this:
> > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> >                  from ../lib/librte_net/net_crc_neon.c:10:
> > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > inlining failed in call to always_inline 'vmull_p64': target specific
> > option mismatch
> >  vmull_p64 (poly64_t a, poly64_t b)
> >  ^~~~~~~~~
> > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Ruifeng, any ideas on how to fix this?
> 
> Gcc build on ThunderX platform is broken. Issue can be seen in some CentOS-8
> OBS builds.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mails.dpdk.org_archives_dev_2020-
> 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1DG
> ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKCUj
> 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> 1jKFC40Bh5hFanzu0A&e=
> I tried tuning compiler flags used, but could not resolve the issue.
> 
> Need help from Marvell to look at this.
> Hi Jerin, do you have any thoughts on this?


Ruifeng, If you are able to reproduce this issue, Could you add "-march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
Fixing the issue?

[main] [dpdk.org] $ git diff
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 00bc4610a..ef65b4bb6 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -96,15 +96,18 @@ implementer_cavium = {
        ],
        'part_number_config': {
                '0xa1': {
-                       'machine_args': ['-mcpu=thunderxt88'],
+                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
+                                        '-mcpu=thunderxt88'],
                        'flags': flags_part_number_thunderx
                },
                '0xa2': {
-                       'machine_args': ['-mcpu=thunderxt81'],
+                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
+                                        '-mcpu=thunderxt81'],
                        'flags': flags_part_number_thunderx
                },
                '0xa3': {
-                       'machine_args': ['-mcpu=thunderxt83'],
+                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
+                                        '-mcpu=thunderxt83'],
                        'flags': flags_part_number_thunderx
                },
                '0xaf': {

> >
> > > --
> > > Kind regards,
> > > Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-25 12:14         ` Jerin Jacob Kollanukkaran
@ 2021-02-25 14:24           ` David Marchand
  2021-03-01  5:40           ` Ruifeng Wang
  1 sibling, 0 replies; 15+ messages in thread
From: David Marchand @ 2021-02-25 14:24 UTC (permalink / raw)
  To: Jerin Jacob Kollanukkaran
  Cc: Ruifeng Wang, Juraj Linkeš, Luca Boccassi, stable, nd

On Thu, Feb 25, 2021 at 1:15 PM Jerin Jacob Kollanukkaran
<jerinj@marvell.com> wrote:
> > Hi Jerin, do you have any thoughts on this?
>
>
> Ruifeng, If you are able to reproduce this issue, Could you add "-march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
> Fixing the issue?
>
> [main] [dpdk.org] $ git diff
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 00bc4610a..ef65b4bb6 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -96,15 +96,18 @@ implementer_cavium = {
>         ],
>         'part_number_config': {
>                 '0xa1': {
> -                       'machine_args': ['-mcpu=thunderxt88'],
> +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> +                                        '-mcpu=thunderxt88'],
>                         'flags': flags_part_number_thunderx
>                 },
>                 '0xa2': {
> -                       'machine_args': ['-mcpu=thunderxt81'],
> +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> +                                        '-mcpu=thunderxt81'],
>                         'flags': flags_part_number_thunderx
>                 },
>                 '0xa3': {
> -                       'machine_args': ['-mcpu=thunderxt83'],
> +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> +                                        '-mcpu=thunderxt83'],
>                         'flags': flags_part_number_thunderx
>                 },
>                 '0xaf': {
>


In OBS, for Centos 8:
[  539s] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.Jlqu02
[  539s] + umask 022
[  539s] + cd /home/abuild/rpmbuild/BUILD
[  539s] + cd dpdk-1614261881.2a428852a
[  539s] + ninja-build -v -C arm64-armv8a-linux-gcc
[  539s] ninja: Entering directory `arm64-armv8a-linux-gcc'
[  539s] [1/2573] /usr/libexec/platform-python
../buildtools/map_to_win.py
/home/abuild/rpmbuild/BUILD/dpdk-1614261881.2a428852a/lib/librte_telemetry/version.map
lib/rte_telemetry_exports.def
[  539s] [2/2573] /usr/libexec/platform-python
../buildtools/map_to_win.py
/home/abuild/rpmbuild/BUILD/dpdk-1614261881.2a428852a/lib/librte_kvargs/version.map
lib/rte_kvargs_exports.def
[  539s] [3/2573] /usr/libexec/platform-python
../buildtools/map_to_win.py
/home/abuild/rpmbuild/BUILD/dpdk-1614261881.2a428852a/lib/librte_telemetry/version.map
lib/rte_telemetry_mingw.map
[  539s] [4/2573] /usr/libexec/platform-python
../buildtools/map_to_win.py
/home/abuild/rpmbuild/BUILD/dpdk-1614261881.2a428852a/lib/librte_kvargs/version.map
lib/rte_kvargs_mingw.map
[  540s] [5/2573] /usr/libexec/platform-python
../buildtools/map_to_win.py
/home/abuild/rpmbuild/BUILD/dpdk-1614261881.2a428852a/lib/librte_rcu/version.map
lib/rte_rcu_exports.def
[  540s] [6/2573] cc -Ilib/76b5a35@@rte_eal@sta -Ilib -I../lib -I.
-I../ -Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal
-Ilib/librte_kvargs -I../lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../lib/librte_telemetry/../librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -fdiagnostics-color=always -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h
-Wextra -Wcast-qual -Wdeprecated -Wformat -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 -fcommon -Werror -fPIC
-march=armv8.1-a+crc+crypto+lse -mcpu=thunderxt88
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
'-DABI_VERSION="21.2"' -DRTE_LIBEAL_USE_GETENTROPY  -MD -MQ
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o'
-MF 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o.d'
-o 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o'
-c ../lib/librte_eal/common/eal_common_cpuflags.c
[  540s] FAILED:
lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o
[  540s] cc -Ilib/76b5a35@@rte_eal@sta -Ilib -I../lib -I. -I../
-Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal
-Ilib/librte_kvargs -I../lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../lib/librte_telemetry/../librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -fdiagnostics-color=always -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h
-Wextra -Wcast-qual -Wdeprecated -Wformat -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 -fcommon -Werror -fPIC
-march=armv8.1-a+crc+crypto+lse -mcpu=thunderxt88
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
'-DABI_VERSION="21.2"' -DRTE_LIBEAL_USE_GETENTROPY  -MD -MQ
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o'
-MF 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o.d'
-o 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_cpuflags.c.o'
-c ../lib/librte_eal/common/eal_common_cpuflags.c
[  540s] cc1: error: switch -mcpu=armv8-a conflicts with
-march=armv8.1-a switch [-Werror]
[  540s] cc1: all warnings being treated as errors
[  540s] [7/2573] cc -Ilib/76b5a35@@rte_eal@sta -Ilib -I../lib -I.
-I../ -Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal
-Ilib/librte_kvargs -I../lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../lib/librte_telemetry/../librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -fdiagnostics-color=always -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h
-Wextra -Wcast-qual -Wdeprecated -Wformat -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 -fcommon -Werror -fPIC
-march=armv8.1-a+crc+crypto+lse -mcpu=thunderxt88
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
'-DABI_VERSION="21.2"' -DRTE_LIBEAL_USE_GETENTROPY  -MD -MQ
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o' -MF
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o.d' -o
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o' -c
../lib/librte_eal/common/eal_common_class.c
[  540s] FAILED: lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o
[  540s] cc -Ilib/76b5a35@@rte_eal@sta -Ilib -I../lib -I. -I../
-Iconfig -I../config -Ilib/librte_eal/include
-I../lib/librte_eal/include -Ilib/librte_eal/linux/include
-I../lib/librte_eal/linux/include -Ilib/librte_eal/arm/include
-I../lib/librte_eal/arm/include -Ilib/librte_eal/common
-I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal
-Ilib/librte_kvargs -I../lib/librte_kvargs
-Ilib/librte_telemetry/../librte_metrics
-I../lib/librte_telemetry/../librte_metrics -Ilib/librte_telemetry
-I../lib/librte_telemetry -fdiagnostics-color=always -pipe
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -include rte_config.h
-Wextra -Wcast-qual -Wdeprecated -Wformat -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 -fcommon -Werror -fPIC
-march=armv8.1-a+crc+crypto+lse -mcpu=thunderxt88
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation
'-DABI_VERSION="21.2"' -DRTE_LIBEAL_USE_GETENTROPY  -MD -MQ
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o' -MF
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o.d' -o
'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_class.c.o' -c
../lib/librte_eal/common/eal_common_class.c
[  540s] cc1: error: switch -mcpu=armv8-a conflicts with
-march=armv8.1-a switch [-Werror]
[  540s] cc1: all warnings being treated as errors

For the full log:
https://build.opensuse.org/build/home:dmarchan/home_bluca_dpdk_CentOS_8/aarch64/dpdk/_log



-- 
David Marchand


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-02-25 12:14         ` Jerin Jacob Kollanukkaran
  2021-02-25 14:24           ` David Marchand
@ 2021-03-01  5:40           ` Ruifeng Wang
  2021-03-07 13:35             ` Jerin Jacob Kollanukkaran
  1 sibling, 1 reply; 15+ messages in thread
From: Ruifeng Wang @ 2021-03-01  5:40 UTC (permalink / raw)
  To: jerinj, Juraj Linkeš, Luca Boccassi, stable; +Cc: david.marchand, nd, nd

> -----Original Message-----
> From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Sent: Thursday, February 25, 2021 8:15 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> stable@dpdk.org
> Cc: david.marchand@redhat.com; nd <nd@arm.com>
> Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> 
> > -----Original Message-----
> > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > Sent: Saturday, February 20, 2021 9:13 AM
> > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> > <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>
> > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine
> > args
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > > -----Original Message-----
> > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > Sent: Friday, February 19, 2021 8:10 PM
> > > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > > david.marchand@redhat.com
> > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Luca Boccassi <bluca@debian.org>
> > > > Sent: Friday, February 19, 2021 12:33 PM
> > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > david.marchand@redhat.com
> > > > Subject: Re: [PATCH 20.11] config/arm: replace native machine args
> > > >
> > > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > > -----Original Message-----
> > > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > > To: stable@dpdk.org
> > > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > david.marchand@redhat.com
> > > > > > Subject: [PATCH 20.11] config/arm: replace native machine args
> > > > > >
> > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > >
> > > > > > [ backported from upstream commit
> > > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > > >
> > > > > > There are compiler issues when building with -mcpu=native with
> > > > > > popular compilers, such as GCC-8.4:
> > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1:
> error:
> > > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > > target specific option mismatch
> > > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > >
> > > > > > and clang:
> > > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > __ARM_FEATURE_ATOMICS
> > > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > > >
> > > > > > Fix this by always specifying the proper machine args and
> > > > > > never using the native flags.
> > > > > >
> > > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > > arguments")
> > > > > >
> > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > > ---
> > > > > > This is a crude backport, but it fixes the build for arm64.
> > > > > > It's a release blocker for 20.11.1, so I would appreciate a quick
> review.
> > > > > > Thanks!
> > > > >
> > > > > What does this fix? With or without the below change, the native
> > > > > machine
> > > > args are not used. The patch shoudn't actually change the
> > > > configuration of the build at all, so I'm a bit confused.
> > > >
> > > > It fixes the build on some build workers with thunderx hardware -
> > > > without this I get failures like:
> > > >
> > > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > > 'vmull_p64': target specific option mismatch
> > > >
> > >
> > > I tried the patch and I'm seeing the same errors on a ThunderX
> > > server (with and without the patch). Is this actually the right patch?
> > >
> > > One of the four failures looks like this:
> > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > inlining failed in call to always_inline 'vmull_p64': target
> > > specific option mismatch
> > >  vmull_p64 (poly64_t a, poly64_t b)
> > >  ^~~~~~~~~
> > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Ruifeng, any ideas on how to fix this?
> >
> > Gcc build on ThunderX platform is broken. Issue can be seen in some
> > CentOS-8 OBS builds.
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__mails.dpdk.org_archives_dev_2020-
> >
> 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> DG
> >
> ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKC
> Uj
> > 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> > 1jKFC40Bh5hFanzu0A&e=
> > I tried tuning compiler flags used, but could not resolve the issue.
> >
> > Need help from Marvell to look at this.
> > Hi Jerin, do you have any thoughts on this?
> 
> 
> Ruifeng, If you are able to reproduce this issue, Could you add "-
> march=armv8.1-a+crc+crypto" In ThunderX config  and check is this Fixing the
> issue?
> 
> [main] [dpdk.org] $ git diff
> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> 00bc4610a..ef65b4bb6 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -96,15 +96,18 @@ implementer_cavium = {
>         ],
>         'part_number_config': {
>                 '0xa1': {
> -                       'machine_args': ['-mcpu=thunderxt88'],
> +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> +                                        '-mcpu=thunderxt88'],
>                         'flags': flags_part_number_thunderx
>                 },
>                 '0xa2': {
> -                       'machine_args': ['-mcpu=thunderxt81'],
> +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> +                                        '-mcpu=thunderxt81'],
>                         'flags': flags_part_number_thunderx
>                 },
>                 '0xa3': {
> -                       'machine_args': ['-mcpu=thunderxt83'],
> +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> +                                        '-mcpu=thunderxt83'],
>                         'flags': flags_part_number_thunderx
>                 },
>                 '0xaf': {
> 

Hi Jerin,

The patch doesn't work. Build failed at link stage.
I used gcc 8.4 and tried build on thunderxt88.

Logs as below:
[2513/2527] Linking target app/test/dpdk-test
FAILED: app/test/dpdk-test 
cc  -o app/test/dpdk-test app/test/dpdk-test.p/commands.c.o app/test/dpdk-test.p/packet_burst_generator.c.o app/test/dpdk-test.p/test.c.o app/test/dpdk-test.p/test_acl.c.o app/test/dpdk-test.p/test_alarm.c.o app/test/dpdk-test.p/test_atomic.c.o app/test/dpdk-test.p/test_barrier.c.o app/test/dpdk-test.p/test_bitops.c.o app/test/dpdk-test.p/test_bitmap.c.o app/test/dpdk-test.p/test_bpf.c.o app/test/dpdk-test.p/test_byteorder.c.o app/test/dpdk-test.p/test_cmdline.c.o app/test/dpdk-test.p/test_cmdline_cirbuf.c.o app/test/dpdk-test.p/test_cmdline_etheraddr.c.o app/test/dpdk-test.p/test_cmdline_ipaddr.c.o app/test/dpdk-test.p/test_cmdline_lib.c.o app/test/dpdk-test.p/test_cmdline_num.c.o app/test/dpdk-test.p/test_cmdline_portlist.c.o app/test/dpdk-test.p/test_cmdline_string.c.o app/test/dpdk-test.p/test_common.c.o app/test/dpdk-test.p/test_cpuflags.c.o app/test/dpdk-test.p/test_crc.c.o app/test/dpdk-test.p/test_cryptodev.c.o app/test/dpdk-test.p/test_cryptodev_asym.c.o app/test/dpdk-test.p/test_cryptodev_blockcipher.c.o app/test/dpdk-test.p/test_cryptodev_security_pdcp.c.o app/test/dpdk-test.p/test_cycles.c.o app/test/dpdk-test.p/test_debug.c.o app/test/dpdk-test.p/test_distributor.c.o app/test/dpdk-test.p/test_distributor_perf.c.o app/test/dpdk-test.p/test_eal_flags.c.o app/test/dpdk-test.p/test_eal_fs.c.o app/test/dpdk-test.p/test_efd.c.o app/test/dpdk-test.p/test_efd_perf.c.o app/test/dpdk-test.p/test_errno.c.o app/test/dpdk-test.p/test_ethdev_link.c.o app/test/dpdk-test.p/test_event_crypto_adapter.c.o app/test/dpdk-test.p/test_event_eth_rx_adapter.c.o app/test/dpdk-test.p/test_event_ring.c.o app/test/dpdk-test.p/test_event_timer_adapter.c.o app/test/dpdk-test.p/test_eventdev.c.o app/test/dpdk-test.p/test_external_mem.c.o app/test/dpdk-test.p/test_fbarray.c.o app/test/dpdk-test.p/test_fib.c.o app/test/dpdk-test.p/test_fib_perf.c.o app/test/dpdk-test.p/test_fib6.c.o app/test/dpdk-test.p/test_fib6_perf.c.o app/test/dpdk-test.p/test_func_reentrancy.c.o app/test/dpdk-test.p/test_flow_classify.c.o app/test/dpdk-test.p/test_graph.c.o app/test/dpdk-test.p/test_graph_perf.c.o app/test/dpdk-test.p/test_hash.c.o app/test/dpdk-test.p/test_hash_functions.c.o app/test/dpdk-test.p/test_hash_multiwriter.c.o app/test/dpdk-test.p/test_hash_readwrite.c.o app/test/dpdk-test.p/test_hash_perf.c.o app/test/dpdk-test.p/test_hash_readwrite_lf_perf.c.o app/test/dpdk-test.p/test_interrupts.c.o app/test/dpdk-test.p/test_ipfrag.c.o app/test/dpdk-test.p/test_ipsec.c.o app/test/dpdk-test.p/test_ipsec_sad.c.o app/test/dpdk-test.p/test_ipsec_perf.c.o app/test/dpdk-test.p/test_kni.c.o app/test/dpdk-test.p/test_kvargs.c.o app/test/dpdk-test.p/test_lcores.c.o app/test/dpdk-test.p/test_logs.c.o app/test/dpdk-test.p/test_lpm.c.o app/test/dpdk-test.p/test_lpm6.c.o app/test/dpdk-test.p/test_lpm6_perf.c.o app/test/dpdk-test.p/test_lpm_perf.c.o app/test/dpdk-test.p/test_malloc.c.o app/test/dpdk-test.p/test_mbuf.c.o app/test/dpdk-test.p/test_member.c.o app/test/dpdk-test.p/test_member_perf.c.o app/test/dpdk-test.p/test_memcpy.c.o app/test/dpdk-test.p/test_memcpy_perf.c.o app/test/dpdk-test.p/test_memory.c.o app/test/dpdk-test.p/test_mempool.c.o app/test/dpdk-test.p/test_mempool_perf.c.o app/test/dpdk-test.p/test_memzone.c.o app/test/dpdk-test.p/test_meter.c.o app/test/dpdk-test.p/test_metrics.c.o app/test/dpdk-test.p/test_mcslock.c.o app/test/dpdk-test.p/test_mp_secondary.c.o app/test/dpdk-test.p/test_per_lcore.c.o app/test/dpdk-test.p/test_pmd_perf.c.o app/test/dpdk-test.p/test_power.c.o app/test/dpdk-test.p/test_power_cpufreq.c.o app/test/dpdk-test.p/test_power_kvm_vm.c.o app/test/dpdk-test.p/test_prefetch.c.o app/test/dpdk-test.p/test_rand_perf.c.o app/test/dpdk-test.p/test_rawdev.c.o app/test/dpdk-test.p/test_rcu_qsbr.c.o app/test/dpdk-test.p/test_rcu_qsbr_perf.c.o app/test/dpdk-test.p/test_reciprocal_division.c.o app/test/dpdk-test.p/test_reciprocal_division_perf.c.o app/test/dpdk-test.p/test_red.c.o app/test/dpdk-test.p/test_reorder.c.o app/test/dpdk-test.p/test_rib.c.o app/test/dpdk-test.p/test_rib6.c.o app/test/dpdk-test.p/test_ring.c.o app/test/dpdk-test.p/test_ring_mpmc_stress.c.o app/test/dpdk-test.p/test_ring_hts_stress.c.o app/test/dpdk-test.p/test_ring_mt_peek_stress.c.o app/test/dpdk-test.p/test_ring_mt_peek_stress_zc.c.o app/test/dpdk-test.p/test_ring_perf.c.o app/test/dpdk-test.p/test_ring_rts_stress.c.o app/test/dpdk-test.p/test_ring_st_peek_stress.c.o app/test/dpdk-test.p/test_ring_st_peek_stress_zc.c.o app/test/dpdk-test.p/test_ring_stress.c.o app/test/dpdk-test.p/test_rwlock.c.o app/test/dpdk-test.p/test_sched.c.o app/test/dpdk-test.p/test_security.c.o app/test/dpdk-test.p/test_service_cores.c.o app/test/dpdk-test.p/test_spinlock.c.o app/test/dpdk-test.p/test_stack.c.o app/test/dpdk-test.p/test_stack_perf.c.o app/test/dpdk-test.p/test_string_fns.c.o app/test/dpdk-test.p/test_table.c.o app/test/dpdk-test.p/test_table_acl.c.o app/test/dpdk-test.p/test_table_combined.c.o app/test/dpdk-test.p/test_table_pipeline.c.o app/test/dpdk-test.p/test_table_ports.c.o app/test/dpdk-test.p/test_table_tables.c.o app/test/dpdk-test.p/test_tailq.c.o app/test/dpdk-test.p/test_thash.c.o app/test/dpdk-test.p/test_timer.c.o app/test/dpdk-test.p/test_timer_perf.c.o app/test/dpdk-test.p/test_timer_racecond.c.o app/test/dpdk-test.p/test_timer_secondary.c.o app/test/dpdk-test.p/test_ticketlock.c.o app/test/dpdk-test.p/test_trace.c.o app/test/dpdk-test.p/test_trace_register.c.o app/test/dpdk-test.p/test_trace_perf.c.o app/test/dpdk-test.p/test_version.c.o app/test/dpdk-test.p/virtual_pmd.c.o app/test/dpdk-test.p/test_telemetry_json.c.o app/test/dpdk-test.p/test_telemetry_data.c.o app/test/dpdk-test.p/test_link_bonding.c.o app/test/dpdk-test.p/test_link_bonding_rssconf.c.o app/test/dpdk-test.p/test_link_bonding_mode4.c.o app/test/dpdk-test.p/test_pmd_ring_perf.c.o app/test/dpdk-test.p/test_pmd_ring.c.o app/test/dpdk-test.p/test_event_eth_tx_adapter.c.o app/test/dpdk-test.p/test_bitratestats.c.o app/test/dpdk-test.p/test_latencystats.c.o app/test/dpdk-test.p/sample_packet_forward.c.o app/test/dpdk-test.p/test_pdump.c.o app/test/dpdk-test.p/test_compressdev.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--whole-archive -Wl,--start-group lib/librte_node.a lib/librte_graph.a lib/librte_bpf.a lib/librte_flow_classify.a lib/librte_pipeline.a lib/librte_table.a lib/librte_port.a lib/librte_fib.a lib/librte_ipsec.a lib/librte_vhost.a lib/librte_stack.a lib/librte_security.a lib/librte_sched.a lib/librte_reorder.a lib/librte_rib.a lib/librte_regexdev.a lib/librte_rawdev.a lib/librte_pdump.a lib/librte_power.a lib/librte_member.a lib/librte_lpm.a lib/librte_latencystats.a lib/librte_kni.a lib/librte_jobstats.a lib/librte_ip_frag.a lib/librte_gso.a lib/librte_gro.a lib/librte_eventdev.a lib/librte_efd.a lib/librte_distributor.a lib/librte_cryptodev.a lib/librte_compressdev.a lib/librte_cfgfile.a lib/librte_bitratestats.a lib/librte_bbdev.a lib/librte_acl.a lib/librte_timer.a lib/librte_hash.a lib/librte_metrics.a lib/librte_cmdline.a lib/librte_pci.a lib/librte_ethdev.a lib/librte_meter.a lib/librte_net.a lib/librte_mbuf.a lib/librte_mempool.a lib/librte_rcu.a lib/librte_ring.a lib/librte_eal.a lib/librte_telemetry.a lib/librte_kvargs.a drivers/librte_common_cpt.a drivers/librte_common_dpaax.a drivers/librte_common_iavf.a drivers/librte_common_octeontx.a drivers/librte_common_octeontx2.a drivers/librte_common_sfc_efx.a drivers/librte_bus_dpaa.a drivers/librte_bus_fslmc.a drivers/librte_bus_ifpga.a drivers/librte_bus_pci.a drivers/librte_bus_vdev.a drivers/librte_bus_vmbus.a drivers/librte_common_mlx5.a drivers/librte_common_qat.a drivers/librte_mempool_bucket.a drivers/librte_mempool_dpaa.a drivers/librte_mempool_dpaa2.a drivers/librte_mempool_octeontx.a drivers/librte_mempool_octeontx2.a drivers/librte_mempool_ring.a drivers/librte_mempool_stack.a drivers/librte_net_af_packet.a drivers/librte_net_ark.a drivers/librte_net_atlantic.a drivers/librte_net_avp.a drivers/librte_net_axgbe.a drivers/librte_net_bond.a drivers/librte_net_bnx2x.a drivers/librte_net_bnxt.a drivers/librte_net_cxgbe.a drivers/librte_net_dpaa.a drivers/librte_net_dpaa2.a drivers/librte_net_e1000.a drivers/librte_net_ena.a drivers/librte_net_enetc.a drivers/librte_net_enic.a drivers/librte_net_failsafe.a drivers/librte_net_fm10k.a drivers/librte_net_i40e.a drivers/librte_net_hinic.a drivers/librte_net_hns3.a drivers/librte_net_iavf.a drivers/librte_net_ice.a drivers/librte_net_igc.a drivers/librte_net_ionic.a drivers/librte_net_ixgbe.a drivers/librte_net_kni.a drivers/librte_net_liquidio.a drivers/librte_net_memif.a drivers/librte_net_mlx4.a drivers/librte_net_mlx5.a drivers/librte_net_netvsc.a drivers/librte_net_nfp.a drivers/librte_net_null.a drivers/librte_net_octeontx.a drivers/librte_net_octeontx2.a drivers/librte_net_octeontx_ep.a drivers/librte_net_pfe.a drivers/librte_net_qede.a drivers/librte_net_ring.a drivers/librte_net_sfc.a drivers/librte_net_softnic.a drivers/librte_net_tap.a drivers/librte_net_thunderx.a drivers/librte_net_txgbe.a drivers/librte_net_vdev_netvsc.a drivers/librte_net_vhost.a drivers/librte_net_virtio.a drivers/librte_net_vmxnet3.a drivers/librte_raw_dpaa2_cmdif.a drivers/librte_raw_dpaa2_qdma.a drivers/librte_raw_ntb.a drivers/librte_raw_octeontx2_dma.a drivers/librte_raw_octeontx2_ep.a drivers/librte_raw_skeleton.a drivers/librte_crypto_bcmfs.a drivers/librte_crypto_caam_jr.a drivers/librte_crypto_ccp.a drivers/librte_crypto_dpaa_sec.a drivers/librte_crypto_dpaa2_sec.a drivers/librte_crypto_nitrox.a drivers/librte_crypto_null.a drivers/librte_crypto_octeontx.a drivers/librte_crypto_octeontx2.a drivers/librte_crypto_openssl.a drivers/librte_crypto_scheduler.a drivers/librte_crypto_virtio.a drivers/librte_compress_mlx5.a drivers/librte_compress_octeontx.a drivers/librte_compress_zlib.a drivers/librte_regex_mlx5.a drivers/librte_regex_octeontx2.a drivers/librte_vdpa_ifc.a drivers/librte_vdpa_mlx5.a drivers/librte_event_dpaa.a drivers/librte_event_dpaa2.a drivers/librte_event_octeontx2.a drivers/librte_event_opdl.a drivers/librte_event_skeleton.a drivers/librte_event_sw.a drivers/librte_event_dsw.a drivers/librte_event_octeontx.a drivers/librte_baseband_null.a drivers/librte_baseband_turbo_sw.a drivers/librte_baseband_fpga_lte_fec.a drivers/librte_baseband_fpga_5gnr_fec.a drivers/librte_baseband_acc100.a -Wl,--no-whole-archive -Wl,--no-as-needed -pthread -lm -ldl -lnuma /usr/lib/aarch64-linux-gnu/libz.so -lmlx5 -libverbs /usr/lib/aarch64-linux-gnu/libcrypto.so -lmlx4 -libverbs -lmlx5 -libverbs -lmlx5 -libverbs -lmlx5 -libverbs -lmlx5 -libverbs -Wl,--end-group -Wl,-rpath,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
app/test/dpdk-test.p/test_hash_perf.c.o: In function `test_hash_perf':
test_hash_perf.c:(.text+0x1c74): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
test_hash_perf.c:(.text+0x1d8c): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
test_hash_perf.c:(.text+0x2508): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
collect2: error: ld returned 1 exit status
[2527/2527] Linking target app/dpdk-test-bbdev
ninja: build stopped: subcommand failed.

> > >
> > > > --
> > > > Kind regards,
> > > > Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-03-01  5:40           ` Ruifeng Wang
@ 2021-03-07 13:35             ` Jerin Jacob Kollanukkaran
  2021-03-08  3:23               ` Ruifeng Wang
  0 siblings, 1 reply; 15+ messages in thread
From: Jerin Jacob Kollanukkaran @ 2021-03-07 13:35 UTC (permalink / raw)
  To: Ruifeng Wang, Juraj Linkeš,
	Luca Boccassi, stable, dev, Thomas Monjalon,
	Ashwin Sekhar Thalakalath Kottilveetil, Andrew Pinski
  Cc: david.marchand, nd, nd



> -----Original Message-----
> From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> Sent: Monday, March 1, 2021 11:10 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj Linkeš
> <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> stable@dpdk.org
> Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine args
> 
> External Email
> 
> ----------------------------------------------------------------------
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > Sent: Thursday, February 25, 2021 8:15 PM
> > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > stable@dpdk.org
> > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> >
> > > -----Original Message-----
> > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > Sent: Saturday, February 20, 2021 9:13 AM
> > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> > > <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> > > <jerinj@marvell.com>
> > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine
> > > args
> > >
> > > External Email
> > >
> > > --------------------------------------------------------------------
> > > --
> > > > -----Original Message-----
> > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > Sent: Friday, February 19, 2021 8:10 PM
> > > > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > > > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > > > david.marchand@redhat.com
> > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Luca Boccassi <bluca@debian.org>
> > > > > Sent: Friday, February 19, 2021 12:33 PM
> > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > david.marchand@redhat.com
> > > > > Subject: Re: [PATCH 20.11] config/arm: replace native machine
> > > > > args
> > > > >
> > > > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > > > To: stable@dpdk.org
> > > > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > david.marchand@redhat.com
> > > > > > > Subject: [PATCH 20.11] config/arm: replace native machine
> > > > > > > args
> > > > > > >
> > > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > >
> > > > > > > [ backported from upstream commit
> > > > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > > > >
> > > > > > > There are compiler issues when building with -mcpu=native
> > > > > > > with popular compilers, such as GCC-8.4:
> > > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > > ../lib/librte_net/net_crc_neon.c: In function ‘crcr32_folding_round’:
> > > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1:
> > error:
> > > > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > > > target specific option mismatch
> > > > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > > >
> > > > > > > and clang:
> > > > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > __ARM_FEATURE_ATOMICS
> > > > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > > > >
> > > > > > > Fix this by always specifying the proper machine args and
> > > > > > > never using the native flags.
> > > > > > >
> > > > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > > > arguments")
> > > > > > >
> > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > > > ---
> > > > > > > This is a crude backport, but it fixes the build for arm64.
> > > > > > > It's a release blocker for 20.11.1, so I would appreciate a
> > > > > > > quick
> > review.
> > > > > > > Thanks!
> > > > > >
> > > > > > What does this fix? With or without the below change, the
> > > > > > native machine
> > > > > args are not used. The patch shoudn't actually change the
> > > > > configuration of the build at all, so I'm a bit confused.
> > > > >
> > > > > It fixes the build on some build workers with thunderx hardware
> > > > > - without this I get failures like:
> > > > >
> > > > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > > > 'vmull_p64': target specific option mismatch
> > > > >
> > > >
> > > > I tried the patch and I'm seeing the same errors on a ThunderX
> > > > server (with and without the patch). Is this actually the right patch?
> > > >
> > > > One of the four failures looks like this:
> > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > inlining failed in call to always_inline 'vmull_p64': target
> > > > specific option mismatch
> > > >  vmull_p64 (poly64_t a, poly64_t b)  ^~~~~~~~~
> > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > > Ruifeng, any ideas on how to fix this?
> > >
> > > Gcc build on ThunderX platform is broken. Issue can be seen in some
> > > CentOS-8 OBS builds.
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > 3A__mails.dpdk.org_archives_dev_2020-
> > >
> > 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> > DG
> > >
> > ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKC
> > Uj
> > > 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> > > 1jKFC40Bh5hFanzu0A&e=
> > > I tried tuning compiler flags used, but could not resolve the issue.
> > >
> > > Need help from Marvell to look at this.
> > > Hi Jerin, do you have any thoughts on this?
> >
> >
> > Ruifeng, If you are able to reproduce this issue, Could you add "-
> > march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
> > Fixing the issue?
> >
> > [main] [dpdk.org] $ git diff
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 00bc4610a..ef65b4bb6 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -96,15 +96,18 @@ implementer_cavium = {
> >         ],
> >         'part_number_config': {
> >                 '0xa1': {
> > -                       'machine_args': ['-mcpu=thunderxt88'],
> > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > +                                        '-mcpu=thunderxt88'],
> >                         'flags': flags_part_number_thunderx
> >                 },
> >                 '0xa2': {
> > -                       'machine_args': ['-mcpu=thunderxt81'],
> > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > +                                        '-mcpu=thunderxt81'],
> >                         'flags': flags_part_number_thunderx
> >                 },
> >                 '0xa3': {
> > -                       'machine_args': ['-mcpu=thunderxt83'],
> > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > +                                        '-mcpu=thunderxt83'],
> >                         'flags': flags_part_number_thunderx
> >                 },
> >                 '0xaf': {
> >
> 
> Hi Jerin,
> 
> The patch doesn't work. Build failed at link stage.
> I used gcc 8.4 and tried build on thunderxt88.



Hi Ruifeng,

I talked to compiler experts here in Marvell. It looks like compiler issue, As a workaround couple of these could try:
1) Reduce the external libraries linked to the application like mlx5 etc
2) Add -mcmodel=large flag will fix "relocation truncated to fit" issue as testing purpose as we are not sure about the implication of this flag.


> 
> Logs as below:
> [2513/2527] Linking target app/test/dpdk-test
> FAILED: app/test/dpdk-test
> cc  -o app/test/dpdk-test app/test/dpdk-test.p/commands.c.o app/test/dpdk-
> test.p/packet_burst_generator.c.o app/test/dpdk-test.p/test.c.o app/test/dpdk-
> test.p/test_acl.c.o app/test/dpdk-test.p/test_alarm.c.o app/test/dpdk-
> test.p/test_atomic.c.o app/test/dpdk-test.p/test_barrier.c.o app/test/dpdk-
> test.p/test_bitops.c.o app/test/dpdk-test.p/test_bitmap.c.o app/test/dpdk-
> test.p/test_bpf.c.o app/test/dpdk-test.p/test_byteorder.c.o app/test/dpdk-
> test.p/test_cmdline.c.o app/test/dpdk-test.p/test_cmdline_cirbuf.c.o
> app/test/dpdk-test.p/test_cmdline_etheraddr.c.o app/test/dpdk-
> test.p/test_cmdline_ipaddr.c.o app/test/dpdk-test.p/test_cmdline_lib.c.o
> app/test/dpdk-test.p/test_cmdline_num.c.o app/test/dpdk-
> test.p/test_cmdline_portlist.c.o app/test/dpdk-test.p/test_cmdline_string.c.o
> app/test/dpdk-test.p/test_common.c.o app/test/dpdk-test.p/test_cpuflags.c.o
> app/test/dpdk-test.p/test_crc.c.o app/test/dpdk-test.p/test_cryptodev.c.o
> app/test/dpdk-test.p/test_cryptodev_asym.c.o app/test/dpdk-
> test.p/test_cryptodev_blockcipher.c.o app/test/dpdk-
> test.p/test_cryptodev_security_pdcp.c.o app/test/dpdk-test.p/test_cycles.c.o
> app/test/dpdk-test.p/test_debug.c.o app/test/dpdk-test.p/test_distributor.c.o
> app/test/dpdk-test.p/test_distributor_perf.c.o app/test/dpdk-
> test.p/test_eal_flags.c.o app/test/dpdk-test.p/test_eal_fs.c.o app/test/dpdk-
> test.p/test_efd.c.o app/test/dpdk-test.p/test_efd_perf.c.o app/test/dpdk-
> test.p/test_errno.c.o app/test/dpdk-test.p/test_ethdev_link.c.o app/test/dpdk-
> test.p/test_event_crypto_adapter.c.o app/test/dpdk-
> test.p/test_event_eth_rx_adapter.c.o app/test/dpdk-test.p/test_event_ring.c.o
> app/test/dpdk-test.p/test_event_timer_adapter.c.o app/test/dpdk-
> test.p/test_eventdev.c.o app/test/dpdk-test.p/test_external_mem.c.o
> app/test/dpdk-test.p/test_fbarray.c.o app/test/dpdk-test.p/test_fib.c.o
> app/test/dpdk-test.p/test_fib_perf.c.o app/test/dpdk-test.p/test_fib6.c.o
> app/test/dpdk-test.p/test_fib6_perf.c.o app/test/dpdk-
> test.p/test_func_reentrancy.c.o app/test/dpdk-test.p/test_flow_classify.c.o
> app/test/dpdk-test.p/test_graph.c.o app/test/dpdk-test.p/test_graph_perf.c.o
> app/test/dpdk-test.p/test_hash.c.o app/test/dpdk-
> test.p/test_hash_functions.c.o app/test/dpdk-test.p/test_hash_multiwriter.c.o
> app/test/dpdk-test.p/test_hash_readwrite.c.o app/test/dpdk-
> test.p/test_hash_perf.c.o app/test/dpdk-test.p/test_hash_readwrite_lf_perf.c.o
> app/test/dpdk-test.p/test_interrupts.c.o app/test/dpdk-test.p/test_ipfrag.c.o
> app/test/dpdk-test.p/test_ipsec.c.o app/test/dpdk-test.p/test_ipsec_sad.c.o
> app/test/dpdk-test.p/test_ipsec_perf.c.o app/test/dpdk-test.p/test_kni.c.o
> app/test/dpdk-test.p/test_kvargs.c.o app/test/dpdk-test.p/test_lcores.c.o
> app/test/dpdk-test.p/test_logs.c.o app/test/dpdk-test.p/test_lpm.c.o
> app/test/dpdk-test.p/test_lpm6.c.o app/test/dpdk-test.p/test_lpm6_perf.c.o
> app/test/dpdk-test.p/test_lpm_perf.c.o app/test/dpdk-test.p/test_malloc.c.o
> app/test/dpdk-test.p/test_mbuf.c.o app/test/dpdk-test.p/test_member.c.o
> app/test/dpdk-test.p/test_member_perf.c.o app/test/dpdk-
> test.p/test_memcpy.c.o app/test/dpdk-test.p/test_memcpy_perf.c.o
> app/test/dpdk-test.p/test_memory.c.o app/test/dpdk-test.p/test_mempool.c.o
> app/test/dpdk-test.p/test_mempool_perf.c.o app/test/dpdk-
> test.p/test_memzone.c.o app/test/dpdk-test.p/test_meter.c.o app/test/dpdk-
> test.p/test_metrics.c.o app/test/dpdk-test.p/test_mcslock.c.o app/test/dpdk-
> test.p/test_mp_secondary.c.o app/test/dpdk-test.p/test_per_lcore.c.o
> app/test/dpdk-test.p/test_pmd_perf.c.o app/test/dpdk-test.p/test_power.c.o
> app/test/dpdk-test.p/test_power_cpufreq.c.o app/test/dpdk-
> test.p/test_power_kvm_vm.c.o app/test/dpdk-test.p/test_prefetch.c.o
> app/test/dpdk-test.p/test_rand_perf.c.o app/test/dpdk-test.p/test_rawdev.c.o
> app/test/dpdk-test.p/test_rcu_qsbr.c.o app/test/dpdk-
> test.p/test_rcu_qsbr_perf.c.o app/test/dpdk-test.p/test_reciprocal_division.c.o
> app/test/dpdk-test.p/test_reciprocal_division_perf.c.o app/test/dpdk-
> test.p/test_red.c.o app/test/dpdk-test.p/test_reorder.c.o app/test/dpdk-
> test.p/test_rib.c.o app/test/dpdk-test.p/test_rib6.c.o app/test/dpdk-
> test.p/test_ring.c.o app/test/dpdk-test.p/test_ring_mpmc_stress.c.o
> app/test/dpdk-test.p/test_ring_hts_stress.c.o app/test/dpdk-
> test.p/test_ring_mt_peek_stress.c.o app/test/dpdk-
> test.p/test_ring_mt_peek_stress_zc.c.o app/test/dpdk-test.p/test_ring_perf.c.o
> app/test/dpdk-test.p/test_ring_rts_stress.c.o app/test/dpdk-
> test.p/test_ring_st_peek_stress.c.o app/test/dpdk-
> test.p/test_ring_st_peek_stress_zc.c.o app/test/dpdk-test.p/test_ring_stress.c.o
> app/test/dpdk-test.p/test_rwlock.c.o app/test/dpdk-test.p/test_sched.c.o
> app/test/dpdk-test.p/test_security.c.o app/test/dpdk-
> test.p/test_service_cores.c.o app/test/dpdk-test.p/test_spinlock.c.o
> app/test/dpdk-test.p/test_stack.c.o app/test/dpdk-test.p/test_stack_perf.c.o
> app/test/dpdk-test.p/test_string_fns.c.o app/test/dpdk-test.p/test_table.c.o
> app/test/dpdk-test.p/test_table_acl.c.o app/test/dpdk-
> test.p/test_table_combined.c.o app/test/dpdk-test.p/test_table_pipeline.c.o
> app/test/dpdk-test.p/test_table_ports.c.o app/test/dpdk-
> test.p/test_table_tables.c.o app/test/dpdk-test.p/test_tailq.c.o app/test/dpdk-
> test.p/test_thash.c.o app/test/dpdk-test.p/test_timer.c.o app/test/dpdk-
> test.p/test_timer_perf.c.o app/test/dpdk-test.p/test_timer_racecond.c.o
> app/test/dpdk-test.p/test_timer_secondary.c.o app/test/dpdk-
> test.p/test_ticketlock.c.o app/test/dpdk-test.p/test_trace.c.o app/test/dpdk-
> test.p/test_trace_register.c.o app/test/dpdk-test.p/test_trace_perf.c.o
> app/test/dpdk-test.p/test_version.c.o app/test/dpdk-test.p/virtual_pmd.c.o
> app/test/dpdk-test.p/test_telemetry_json.c.o app/test/dpdk-
> test.p/test_telemetry_data.c.o app/test/dpdk-test.p/test_link_bonding.c.o
> app/test/dpdk-test.p/test_link_bonding_rssconf.c.o app/test/dpdk-
> test.p/test_link_bonding_mode4.c.o app/test/dpdk-
> test.p/test_pmd_ring_perf.c.o app/test/dpdk-test.p/test_pmd_ring.c.o
> app/test/dpdk-test.p/test_event_eth_tx_adapter.c.o app/test/dpdk-
> test.p/test_bitratestats.c.o app/test/dpdk-test.p/test_latencystats.c.o
> app/test/dpdk-test.p/sample_packet_forward.c.o app/test/dpdk-
> test.p/test_pdump.c.o app/test/dpdk-test.p/test_compressdev.c.o -Wl,--as-
> needed -Wl,--no-undefined -Wl,-O1 -Wl,--whole-archive -Wl,--start-group
> lib/librte_node.a lib/librte_graph.a lib/librte_bpf.a lib/librte_flow_classify.a
> lib/librte_pipeline.a lib/librte_table.a lib/librte_port.a lib/librte_fib.a
> lib/librte_ipsec.a lib/librte_vhost.a lib/librte_stack.a lib/librte_security.a
> lib/librte_sched.a lib/librte_reorder.a lib/librte_rib.a lib/librte_regexdev.a
> lib/librte_rawdev.a lib/librte_pdump.a lib/librte_power.a lib/librte_member.a
> lib/librte_lpm.a lib/librte_latencystats.a lib/librte_kni.a lib/librte_jobstats.a
> lib/librte_ip_frag.a lib/librte_gso.a lib/librte_gro.a lib/librte_eventdev.a
> lib/librte_efd.a lib/librte_distributor.a lib/librte_cryptodev.a
> lib/librte_compressdev.a lib/librte_cfgfile.a lib/librte_bitratestats.a
> lib/librte_bbdev.a lib/librte_acl.a lib/librte_timer.a lib/librte_hash.a
> lib/librte_metrics.a lib/librte_cmdline.a lib/librte_pci.a lib/librte_ethdev.a
> lib/librte_meter.a lib/librte_net.a lib/librte_mbuf.a lib/librte_mempool.a
> lib/librte_rcu.a lib/librte_ring.a lib/librte_eal.a lib/librte_telemetry.a
> lib/librte_kvargs.a drivers/librte_common_cpt.a
> drivers/librte_common_dpaax.a drivers/librte_common_iavf.a
> drivers/librte_common_octeontx.a drivers/librte_common_octeontx2.a
> drivers/librte_common_sfc_efx.a drivers/librte_bus_dpaa.a
> drivers/librte_bus_fslmc.a drivers/librte_bus_ifpga.a drivers/librte_bus_pci.a
> drivers/librte_bus_vdev.a drivers/librte_bus_vmbus.a
> drivers/librte_common_mlx5.a drivers/librte_common_qat.a
> drivers/librte_mempool_bucket.a drivers/librte_mempool_dpaa.a
> drivers/librte_mempool_dpaa2.a drivers/librte_mempool_octeontx.a
> drivers/librte_mempool_octeontx2.a drivers/librte_mempool_ring.a
> drivers/librte_mempool_stack.a drivers/librte_net_af_packet.a
> drivers/librte_net_ark.a drivers/librte_net_atlantic.a drivers/librte_net_avp.a
> drivers/librte_net_axgbe.a drivers/librte_net_bond.a
> drivers/librte_net_bnx2x.a drivers/librte_net_bnxt.a drivers/librte_net_cxgbe.a
> drivers/librte_net_dpaa.a drivers/librte_net_dpaa2.a
> drivers/librte_net_e1000.a drivers/librte_net_ena.a drivers/librte_net_enetc.a
> drivers/librte_net_enic.a drivers/librte_net_failsafe.a
> drivers/librte_net_fm10k.a drivers/librte_net_i40e.a drivers/librte_net_hinic.a
> drivers/librte_net_hns3.a drivers/librte_net_iavf.a drivers/librte_net_ice.a
> drivers/librte_net_igc.a drivers/librte_net_ionic.a drivers/librte_net_ixgbe.a
> drivers/librte_net_kni.a drivers/librte_net_liquidio.a drivers/librte_net_memif.a
> drivers/librte_net_mlx4.a drivers/librte_net_mlx5.a drivers/librte_net_netvsc.a
> drivers/librte_net_nfp.a drivers/librte_net_null.a drivers/librte_net_octeontx.a
> drivers/librte_net_octeontx2.a drivers/librte_net_octeontx_ep.a
> drivers/librte_net_pfe.a drivers/librte_net_qede.a drivers/librte_net_ring.a
> drivers/librte_net_sfc.a drivers/librte_net_softnic.a drivers/librte_net_tap.a
> drivers/librte_net_thunderx.a drivers/librte_net_txgbe.a
> drivers/librte_net_vdev_netvsc.a drivers/librte_net_vhost.a
> drivers/librte_net_virtio.a drivers/librte_net_vmxnet3.a
> drivers/librte_raw_dpaa2_cmdif.a drivers/librte_raw_dpaa2_qdma.a
> drivers/librte_raw_ntb.a drivers/librte_raw_octeontx2_dma.a
> drivers/librte_raw_octeontx2_ep.a drivers/librte_raw_skeleton.a
> drivers/librte_crypto_bcmfs.a drivers/librte_crypto_caam_jr.a
> drivers/librte_crypto_ccp.a drivers/librte_crypto_dpaa_sec.a
> drivers/librte_crypto_dpaa2_sec.a drivers/librte_crypto_nitrox.a
> drivers/librte_crypto_null.a drivers/librte_crypto_octeontx.a
> drivers/librte_crypto_octeontx2.a drivers/librte_crypto_openssl.a
> drivers/librte_crypto_scheduler.a drivers/librte_crypto_virtio.a
> drivers/librte_compress_mlx5.a drivers/librte_compress_octeontx.a
> drivers/librte_compress_zlib.a drivers/librte_regex_mlx5.a
> drivers/librte_regex_octeontx2.a drivers/librte_vdpa_ifc.a
> drivers/librte_vdpa_mlx5.a drivers/librte_event_dpaa.a
> drivers/librte_event_dpaa2.a drivers/librte_event_octeontx2.a
> drivers/librte_event_opdl.a drivers/librte_event_skeleton.a
> drivers/librte_event_sw.a drivers/librte_event_dsw.a
> drivers/librte_event_octeontx.a drivers/librte_baseband_null.a
> drivers/librte_baseband_turbo_sw.a drivers/librte_baseband_fpga_lte_fec.a
> drivers/librte_baseband_fpga_5gnr_fec.a drivers/librte_baseband_acc100.a -
> Wl,--no-whole-archive -Wl,--no-as-needed -pthread -lm -ldl -lnuma
> /usr/lib/aarch64-linux-gnu/libz.so -lmlx5 -libverbs /usr/lib/aarch64-linux-
> gnu/libcrypto.so -lmlx4 -libverbs -lmlx5 -libverbs -lmlx5 -libverbs -lmlx5 -
> libverbs -lmlx5 -libverbs -Wl,--end-group -Wl,-
> rpath,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> app/test/dpdk-test.p/test_hash_perf.c.o: In function `test_hash_perf':
> test_hash_perf.c:(.text+0x1c74): relocation truncated to fit:
> R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> test_hash_perf.c:(.text+0x1d8c): relocation truncated to fit:
> R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> test_hash_perf.c:(.text+0x2508): relocation truncated to fit:
> R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> collect2: error: ld returned 1 exit status [2527/2527] Linking target app/dpdk-
> test-bbdev
> ninja: build stopped: subcommand failed.
> 
> > > >
> > > > > --
> > > > > Kind regards,
> > > > > Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-03-07 13:35             ` Jerin Jacob Kollanukkaran
@ 2021-03-08  3:23               ` Ruifeng Wang
  2021-03-08 12:08                 ` Luca Boccassi
  2021-03-08 18:48                 ` Jerin Jacob
  0 siblings, 2 replies; 15+ messages in thread
From: Ruifeng Wang @ 2021-03-08  3:23 UTC (permalink / raw)
  To: jerinj, Juraj Linkeš,
	Luca Boccassi, stable, dev, thomas,
	Ashwin Sekhar Thalakalath Kottilveetil, Andrew Pinski
  Cc: david.marchand, nd, nd, nd

> -----Original Message-----
> From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Sent: Sunday, March 7, 2021 9:35 PM
> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> stable@dpdk.org; dev@dpdk.org; thomas@monjalon.net; Ashwin Sekhar
> Thalakalath Kottilveetil <asekhar@marvell.com>; Andrew Pinski
> <apinski@marvell.com>
> Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> 
> 
> 
> > -----Original Message-----
> > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > Sent: Monday, March 1, 2021 11:10 AM
> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj Linkeš
> > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > stable@dpdk.org
> > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine
> > args
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > > -----Original Message-----
> > > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > Sent: Thursday, February 25, 2021 8:15 PM
> > > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > stable@dpdk.org
> > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > >
> > > > -----Original Message-----
> > > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > > Sent: Saturday, February 20, 2021 9:13 AM
> > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> > > > <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> > > > <jerinj@marvell.com>
> > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native
> > > > machine args
> > > >
> > > > External Email
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > --
> > > > > -----Original Message-----
> > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > Sent: Friday, February 19, 2021 8:10 PM
> > > > > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > > > > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > > > > david.marchand@redhat.com
> > > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine
> > > > > args
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Luca Boccassi <bluca@debian.org>
> > > > > > Sent: Friday, February 19, 2021 12:33 PM
> > > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > > > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > david.marchand@redhat.com
> > > > > > Subject: Re: [PATCH 20.11] config/arm: replace native machine
> > > > > > args
> > > > > >
> > > > > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > > > > To: stable@dpdk.org
> > > > > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > > david.marchand@redhat.com
> > > > > > > > Subject: [PATCH 20.11] config/arm: replace native machine
> > > > > > > > args
> > > > > > > >
> > > > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > >
> > > > > > > > [ backported from upstream commit
> > > > > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > > > > >
> > > > > > > > There are compiler issues when building with -mcpu=native
> > > > > > > > with popular compilers, such as GCC-8.4:
> > > > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > > > ../lib/librte_net/net_crc_neon.c: In function
> ‘crcr32_folding_round’:
> > > > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1:
> > > error:
> > > > > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > > > > target specific option mismatch
> > > > > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > > > >
> > > > > > > > and clang:
> > > > > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > __ARM_FEATURE_ATOMICS
> > > > > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > > > > >
> > > > > > > > Fix this by always specifying the proper machine args and
> > > > > > > > never using the native flags.
> > > > > > > >
> > > > > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > > > > arguments")
> > > > > > > >
> > > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > > > > ---
> > > > > > > > This is a crude backport, but it fixes the build for arm64.
> > > > > > > > It's a release blocker for 20.11.1, so I would appreciate
> > > > > > > > a quick
> > > review.
> > > > > > > > Thanks!
> > > > > > >
> > > > > > > What does this fix? With or without the below change, the
> > > > > > > native machine
> > > > > > args are not used. The patch shoudn't actually change the
> > > > > > configuration of the build at all, so I'm a bit confused.
> > > > > >
> > > > > > It fixes the build on some build workers with thunderx
> > > > > > hardware
> > > > > > - without this I get failures like:
> > > > > >
> > > > > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > > > > 'vmull_p64': target specific option mismatch
> > > > > >
> > > > >
> > > > > I tried the patch and I'm seeing the same errors on a ThunderX
> > > > > server (with and without the patch). Is this actually the right patch?
> > > > >
> > > > > One of the four failures looks like this:
> > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > > inlining failed in call to always_inline 'vmull_p64': target
> > > > > specific option mismatch
> > > > >  vmull_p64 (poly64_t a, poly64_t b)  ^~~~~~~~~
> > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > Ruifeng, any ideas on how to fix this?
> > > >
> > > > Gcc build on ThunderX platform is broken. Issue can be seen in
> > > > some
> > > > CentOS-8 OBS builds.
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > > 3A__mails.dpdk.org_archives_dev_2020-
> > > >
> > >
> 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> > > DG
> > > >
> > >
> ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKC
> > > Uj
> > > > 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> > > > 1jKFC40Bh5hFanzu0A&e=
> > > > I tried tuning compiler flags used, but could not resolve the issue.
> > > >
> > > > Need help from Marvell to look at this.
> > > > Hi Jerin, do you have any thoughts on this?
> > >
> > >
> > > Ruifeng, If you are able to reproduce this issue, Could you add "-
> > > march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
> > > Fixing the issue?
> > >
> > > [main] [dpdk.org] $ git diff
> > > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > > 00bc4610a..ef65b4bb6 100644
> > > --- a/config/arm/meson.build
> > > +++ b/config/arm/meson.build
> > > @@ -96,15 +96,18 @@ implementer_cavium = {
> > >         ],
> > >         'part_number_config': {
> > >                 '0xa1': {
> > > -                       'machine_args': ['-mcpu=thunderxt88'],
> > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > +                                        '-mcpu=thunderxt88'],
> > >                         'flags': flags_part_number_thunderx
> > >                 },
> > >                 '0xa2': {
> > > -                       'machine_args': ['-mcpu=thunderxt81'],
> > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > +                                        '-mcpu=thunderxt81'],
> > >                         'flags': flags_part_number_thunderx
> > >                 },
> > >                 '0xa3': {
> > > -                       'machine_args': ['-mcpu=thunderxt83'],
> > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > +                                        '-mcpu=thunderxt83'],
> > >                         'flags': flags_part_number_thunderx
> > >                 },
> > >                 '0xaf': {
> > >
> >
> > Hi Jerin,
> >
> > The patch doesn't work. Build failed at link stage.
> > I used gcc 8.4 and tried build on thunderxt88.
> 
> 
> 
> Hi Ruifeng,
> 
> I talked to compiler experts here in Marvell. It looks like compiler issue, As a
> workaround couple of these could try:
> 1) Reduce the external libraries linked to the application like mlx5 etc

I tried building with lots of drivers disabled. Not yet able to get a successful build.

> 2) Add -mcmodel=large flag will fix "relocation truncated to fit" issue as
> testing purpose as we are not sure about the implication of this flag.

Looks like this flag is not supported by gcc 8.4 that I am using.

One thing we can do to overcome the build failure is to switch to default / release build in OBS CI.
OBS CI is running native build, so it could hit this issue when CI job is scheduled to thunderxt88 infrastructure.
I think we should change to do release build (-Dmachine=default) which is more suitable for generic CI verification.
As I checked, release build can pass on my thunderxt88 platform.

What do you think?
> 
> 
> >
> > Logs as below:
> > [2513/2527] Linking target app/test/dpdk-test
> > FAILED: app/test/dpdk-test
> > cc  -o app/test/dpdk-test app/test/dpdk-test.p/commands.c.o
> > app/test/dpdk- test.p/packet_burst_generator.c.o
> > app/test/dpdk-test.p/test.c.o app/test/dpdk- test.p/test_acl.c.o
> > app/test/dpdk-test.p/test_alarm.c.o app/test/dpdk-
> > test.p/test_atomic.c.o app/test/dpdk-test.p/test_barrier.c.o
> > app/test/dpdk- test.p/test_bitops.c.o
> > app/test/dpdk-test.p/test_bitmap.c.o app/test/dpdk-
> > test.p/test_bpf.c.o app/test/dpdk-test.p/test_byteorder.c.o
> > app/test/dpdk- test.p/test_cmdline.c.o
> > app/test/dpdk-test.p/test_cmdline_cirbuf.c.o
> > app/test/dpdk-test.p/test_cmdline_etheraddr.c.o app/test/dpdk-
> > test.p/test_cmdline_ipaddr.c.o
> > app/test/dpdk-test.p/test_cmdline_lib.c.o
> > app/test/dpdk-test.p/test_cmdline_num.c.o app/test/dpdk-
> > test.p/test_cmdline_portlist.c.o
> > app/test/dpdk-test.p/test_cmdline_string.c.o
> > app/test/dpdk-test.p/test_common.c.o
> > app/test/dpdk-test.p/test_cpuflags.c.o
> > app/test/dpdk-test.p/test_crc.c.o
> > app/test/dpdk-test.p/test_cryptodev.c.o
> > app/test/dpdk-test.p/test_cryptodev_asym.c.o app/test/dpdk-
> > test.p/test_cryptodev_blockcipher.c.o app/test/dpdk-
> > test.p/test_cryptodev_security_pdcp.c.o
> > app/test/dpdk-test.p/test_cycles.c.o
> > app/test/dpdk-test.p/test_debug.c.o
> > app/test/dpdk-test.p/test_distributor.c.o
> > app/test/dpdk-test.p/test_distributor_perf.c.o app/test/dpdk-
> > test.p/test_eal_flags.c.o app/test/dpdk-test.p/test_eal_fs.c.o
> > app/test/dpdk- test.p/test_efd.c.o
> > app/test/dpdk-test.p/test_efd_perf.c.o app/test/dpdk-
> > test.p/test_errno.c.o app/test/dpdk-test.p/test_ethdev_link.c.o
> > app/test/dpdk- test.p/test_event_crypto_adapter.c.o app/test/dpdk-
> > test.p/test_event_eth_rx_adapter.c.o
> > app/test/dpdk-test.p/test_event_ring.c.o
> > app/test/dpdk-test.p/test_event_timer_adapter.c.o app/test/dpdk-
> > test.p/test_eventdev.c.o app/test/dpdk-test.p/test_external_mem.c.o
> > app/test/dpdk-test.p/test_fbarray.c.o
> > app/test/dpdk-test.p/test_fib.c.o
> > app/test/dpdk-test.p/test_fib_perf.c.o
> > app/test/dpdk-test.p/test_fib6.c.o
> > app/test/dpdk-test.p/test_fib6_perf.c.o app/test/dpdk-
> > test.p/test_func_reentrancy.c.o
> > app/test/dpdk-test.p/test_flow_classify.c.o
> > app/test/dpdk-test.p/test_graph.c.o
> > app/test/dpdk-test.p/test_graph_perf.c.o
> > app/test/dpdk-test.p/test_hash.c.o app/test/dpdk-
> > test.p/test_hash_functions.c.o
> > app/test/dpdk-test.p/test_hash_multiwriter.c.o
> > app/test/dpdk-test.p/test_hash_readwrite.c.o app/test/dpdk-
> > test.p/test_hash_perf.c.o
> > app/test/dpdk-test.p/test_hash_readwrite_lf_perf.c.o
> > app/test/dpdk-test.p/test_interrupts.c.o
> > app/test/dpdk-test.p/test_ipfrag.c.o
> > app/test/dpdk-test.p/test_ipsec.c.o
> > app/test/dpdk-test.p/test_ipsec_sad.c.o
> > app/test/dpdk-test.p/test_ipsec_perf.c.o
> > app/test/dpdk-test.p/test_kni.c.o app/test/dpdk-test.p/test_kvargs.c.o
> > app/test/dpdk-test.p/test_lcores.c.o
> > app/test/dpdk-test.p/test_logs.c.o app/test/dpdk-test.p/test_lpm.c.o
> > app/test/dpdk-test.p/test_lpm6.c.o
> > app/test/dpdk-test.p/test_lpm6_perf.c.o
> > app/test/dpdk-test.p/test_lpm_perf.c.o
> > app/test/dpdk-test.p/test_malloc.c.o
> > app/test/dpdk-test.p/test_mbuf.c.o
> > app/test/dpdk-test.p/test_member.c.o
> > app/test/dpdk-test.p/test_member_perf.c.o app/test/dpdk-
> > test.p/test_memcpy.c.o app/test/dpdk-test.p/test_memcpy_perf.c.o
> > app/test/dpdk-test.p/test_memory.c.o
> > app/test/dpdk-test.p/test_mempool.c.o
> > app/test/dpdk-test.p/test_mempool_perf.c.o app/test/dpdk-
> > test.p/test_memzone.c.o app/test/dpdk-test.p/test_meter.c.o
> > app/test/dpdk- test.p/test_metrics.c.o
> > app/test/dpdk-test.p/test_mcslock.c.o app/test/dpdk-
> > test.p/test_mp_secondary.c.o app/test/dpdk-test.p/test_per_lcore.c.o
> > app/test/dpdk-test.p/test_pmd_perf.c.o
> > app/test/dpdk-test.p/test_power.c.o
> > app/test/dpdk-test.p/test_power_cpufreq.c.o app/test/dpdk-
> > test.p/test_power_kvm_vm.c.o app/test/dpdk-test.p/test_prefetch.c.o
> > app/test/dpdk-test.p/test_rand_perf.c.o
> > app/test/dpdk-test.p/test_rawdev.c.o
> > app/test/dpdk-test.p/test_rcu_qsbr.c.o app/test/dpdk-
> > test.p/test_rcu_qsbr_perf.c.o
> > app/test/dpdk-test.p/test_reciprocal_division.c.o
> > app/test/dpdk-test.p/test_reciprocal_division_perf.c.o app/test/dpdk-
> > test.p/test_red.c.o app/test/dpdk-test.p/test_reorder.c.o
> > app/test/dpdk- test.p/test_rib.c.o app/test/dpdk-test.p/test_rib6.c.o
> > app/test/dpdk- test.p/test_ring.c.o
> > app/test/dpdk-test.p/test_ring_mpmc_stress.c.o
> > app/test/dpdk-test.p/test_ring_hts_stress.c.o app/test/dpdk-
> > test.p/test_ring_mt_peek_stress.c.o app/test/dpdk-
> > test.p/test_ring_mt_peek_stress_zc.c.o
> > app/test/dpdk-test.p/test_ring_perf.c.o
> > app/test/dpdk-test.p/test_ring_rts_stress.c.o app/test/dpdk-
> > test.p/test_ring_st_peek_stress.c.o app/test/dpdk-
> > test.p/test_ring_st_peek_stress_zc.c.o
> > app/test/dpdk-test.p/test_ring_stress.c.o
> > app/test/dpdk-test.p/test_rwlock.c.o
> > app/test/dpdk-test.p/test_sched.c.o
> > app/test/dpdk-test.p/test_security.c.o app/test/dpdk-
> > test.p/test_service_cores.c.o app/test/dpdk-test.p/test_spinlock.c.o
> > app/test/dpdk-test.p/test_stack.c.o
> > app/test/dpdk-test.p/test_stack_perf.c.o
> > app/test/dpdk-test.p/test_string_fns.c.o
> > app/test/dpdk-test.p/test_table.c.o
> > app/test/dpdk-test.p/test_table_acl.c.o app/test/dpdk-
> > test.p/test_table_combined.c.o
> > app/test/dpdk-test.p/test_table_pipeline.c.o
> > app/test/dpdk-test.p/test_table_ports.c.o app/test/dpdk-
> > test.p/test_table_tables.c.o app/test/dpdk-test.p/test_tailq.c.o
> > app/test/dpdk- test.p/test_thash.c.o
> > app/test/dpdk-test.p/test_timer.c.o app/test/dpdk-
> > test.p/test_timer_perf.c.o
> > app/test/dpdk-test.p/test_timer_racecond.c.o
> > app/test/dpdk-test.p/test_timer_secondary.c.o app/test/dpdk-
> > test.p/test_ticketlock.c.o app/test/dpdk-test.p/test_trace.c.o
> > app/test/dpdk- test.p/test_trace_register.c.o
> > app/test/dpdk-test.p/test_trace_perf.c.o
> > app/test/dpdk-test.p/test_version.c.o
> > app/test/dpdk-test.p/virtual_pmd.c.o
> > app/test/dpdk-test.p/test_telemetry_json.c.o app/test/dpdk-
> > test.p/test_telemetry_data.c.o
> > app/test/dpdk-test.p/test_link_bonding.c.o
> > app/test/dpdk-test.p/test_link_bonding_rssconf.c.o app/test/dpdk-
> > test.p/test_link_bonding_mode4.c.o app/test/dpdk-
> > test.p/test_pmd_ring_perf.c.o app/test/dpdk-test.p/test_pmd_ring.c.o
> > app/test/dpdk-test.p/test_event_eth_tx_adapter.c.o app/test/dpdk-
> > test.p/test_bitratestats.c.o
> > app/test/dpdk-test.p/test_latencystats.c.o
> > app/test/dpdk-test.p/sample_packet_forward.c.o app/test/dpdk-
> > test.p/test_pdump.c.o app/test/dpdk-test.p/test_compressdev.c.o
> > -Wl,--as- needed -Wl,--no-undefined -Wl,-O1 -Wl,--whole-archive
> > -Wl,--start-group lib/librte_node.a lib/librte_graph.a
> > lib/librte_bpf.a lib/librte_flow_classify.a lib/librte_pipeline.a
> > lib/librte_table.a lib/librte_port.a lib/librte_fib.a
> > lib/librte_ipsec.a lib/librte_vhost.a lib/librte_stack.a
> > lib/librte_security.a lib/librte_sched.a lib/librte_reorder.a
> > lib/librte_rib.a lib/librte_regexdev.a lib/librte_rawdev.a
> > lib/librte_pdump.a lib/librte_power.a lib/librte_member.a
> > lib/librte_lpm.a lib/librte_latencystats.a lib/librte_kni.a
> > lib/librte_jobstats.a lib/librte_ip_frag.a lib/librte_gso.a
> > lib/librte_gro.a lib/librte_eventdev.a lib/librte_efd.a
> > lib/librte_distributor.a lib/librte_cryptodev.a
> > lib/librte_compressdev.a lib/librte_cfgfile.a
> > lib/librte_bitratestats.a lib/librte_bbdev.a lib/librte_acl.a
> > lib/librte_timer.a lib/librte_hash.a lib/librte_metrics.a
> > lib/librte_cmdline.a lib/librte_pci.a lib/librte_ethdev.a
> > lib/librte_meter.a lib/librte_net.a lib/librte_mbuf.a
> > lib/librte_mempool.a lib/librte_rcu.a lib/librte_ring.a
> > lib/librte_eal.a lib/librte_telemetry.a lib/librte_kvargs.a
> > drivers/librte_common_cpt.a drivers/librte_common_dpaax.a
> > drivers/librte_common_iavf.a drivers/librte_common_octeontx.a
> > drivers/librte_common_octeontx2.a drivers/librte_common_sfc_efx.a
> > drivers/librte_bus_dpaa.a drivers/librte_bus_fslmc.a
> > drivers/librte_bus_ifpga.a drivers/librte_bus_pci.a
> > drivers/librte_bus_vdev.a drivers/librte_bus_vmbus.a
> > drivers/librte_common_mlx5.a drivers/librte_common_qat.a
> > drivers/librte_mempool_bucket.a drivers/librte_mempool_dpaa.a
> > drivers/librte_mempool_dpaa2.a drivers/librte_mempool_octeontx.a
> > drivers/librte_mempool_octeontx2.a drivers/librte_mempool_ring.a
> > drivers/librte_mempool_stack.a drivers/librte_net_af_packet.a
> > drivers/librte_net_ark.a drivers/librte_net_atlantic.a
> > drivers/librte_net_avp.a drivers/librte_net_axgbe.a
> > drivers/librte_net_bond.a drivers/librte_net_bnx2x.a
> > drivers/librte_net_bnxt.a drivers/librte_net_cxgbe.a
> > drivers/librte_net_dpaa.a drivers/librte_net_dpaa2.a
> > drivers/librte_net_e1000.a drivers/librte_net_ena.a
> > drivers/librte_net_enetc.a drivers/librte_net_enic.a
> > drivers/librte_net_failsafe.a drivers/librte_net_fm10k.a
> > drivers/librte_net_i40e.a drivers/librte_net_hinic.a
> > drivers/librte_net_hns3.a drivers/librte_net_iavf.a
> > drivers/librte_net_ice.a drivers/librte_net_igc.a
> > drivers/librte_net_ionic.a drivers/librte_net_ixgbe.a
> > drivers/librte_net_kni.a drivers/librte_net_liquidio.a
> > drivers/librte_net_memif.a drivers/librte_net_mlx4.a
> > drivers/librte_net_mlx5.a drivers/librte_net_netvsc.a
> > drivers/librte_net_nfp.a drivers/librte_net_null.a
> > drivers/librte_net_octeontx.a drivers/librte_net_octeontx2.a
> > drivers/librte_net_octeontx_ep.a drivers/librte_net_pfe.a
> > drivers/librte_net_qede.a drivers/librte_net_ring.a
> > drivers/librte_net_sfc.a drivers/librte_net_softnic.a
> > drivers/librte_net_tap.a drivers/librte_net_thunderx.a
> > drivers/librte_net_txgbe.a drivers/librte_net_vdev_netvsc.a
> > drivers/librte_net_vhost.a drivers/librte_net_virtio.a
> > drivers/librte_net_vmxnet3.a drivers/librte_raw_dpaa2_cmdif.a
> > drivers/librte_raw_dpaa2_qdma.a drivers/librte_raw_ntb.a
> > drivers/librte_raw_octeontx2_dma.a
> > drivers/librte_raw_octeontx2_ep.a drivers/librte_raw_skeleton.a
> > drivers/librte_crypto_bcmfs.a drivers/librte_crypto_caam_jr.a
> > drivers/librte_crypto_ccp.a drivers/librte_crypto_dpaa_sec.a
> > drivers/librte_crypto_dpaa2_sec.a drivers/librte_crypto_nitrox.a
> > drivers/librte_crypto_null.a drivers/librte_crypto_octeontx.a
> > drivers/librte_crypto_octeontx2.a drivers/librte_crypto_openssl.a
> > drivers/librte_crypto_scheduler.a drivers/librte_crypto_virtio.a
> > drivers/librte_compress_mlx5.a drivers/librte_compress_octeontx.a
> > drivers/librte_compress_zlib.a drivers/librte_regex_mlx5.a
> > drivers/librte_regex_octeontx2.a drivers/librte_vdpa_ifc.a
> > drivers/librte_vdpa_mlx5.a drivers/librte_event_dpaa.a
> > drivers/librte_event_dpaa2.a drivers/librte_event_octeontx2.a
> > drivers/librte_event_opdl.a drivers/librte_event_skeleton.a
> > drivers/librte_event_sw.a drivers/librte_event_dsw.a
> > drivers/librte_event_octeontx.a drivers/librte_baseband_null.a
> > drivers/librte_baseband_turbo_sw.a
> > drivers/librte_baseband_fpga_lte_fec.a
> > drivers/librte_baseband_fpga_5gnr_fec.a
> > drivers/librte_baseband_acc100.a - Wl,--no-whole-archive
> > -Wl,--no-as-needed -pthread -lm -ldl -lnuma
> > /usr/lib/aarch64-linux-gnu/libz.so -lmlx5 -libverbs
> > /usr/lib/aarch64-linux- gnu/libcrypto.so -lmlx4 -libverbs -lmlx5
> > -libverbs -lmlx5 -libverbs -lmlx5 - libverbs -lmlx5 -libverbs
> > -Wl,--end-group -Wl,-
> > rpath,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > app/test/dpdk-test.p/test_hash_perf.c.o: In function `test_hash_perf':
> > test_hash_perf.c:(.text+0x1c74): relocation truncated to fit:
> > R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> > test_hash_perf.c:(.text+0x1d8c): relocation truncated to fit:
> > R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> > test_hash_perf.c:(.text+0x2508): relocation truncated to fit:
> > R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> > collect2: error: ld returned 1 exit status [2527/2527] Linking target
> > app/dpdk- test-bbdev
> > ninja: build stopped: subcommand failed.
> >
> > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Luca Boccassi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
  2021-03-08  3:23               ` Ruifeng Wang
@ 2021-03-08 12:08                 ` Luca Boccassi
  2021-03-08 18:51                   ` [dpdk-stable] [dpdk-dev] " Jerin Jacob
  2021-03-08 18:48                 ` Jerin Jacob
  1 sibling, 1 reply; 15+ messages in thread
From: Luca Boccassi @ 2021-03-08 12:08 UTC (permalink / raw)
  To: Ruifeng Wang, jerinj, Juraj Linkeš,
	stable, dev, thomas, Ashwin Sekhar Thalakalath Kottilveetil,
	Andrew Pinski
  Cc: david.marchand, nd

On Mon, 2021-03-08 at 03:23 +0000, Ruifeng Wang wrote:
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > Sent: Sunday, March 7, 2021 9:35 PM
> > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > stable@dpdk.org; dev@dpdk.org; thomas@monjalon.net; Ashwin Sekhar
> > Thalakalath Kottilveetil <asekhar@marvell.com>; Andrew Pinski
> > <apinski@marvell.com>
> > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > Sent: Monday, March 1, 2021 11:10 AM
> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj Linkeš
> > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > stable@dpdk.org
> > > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine
> > > args
> > > 
> > > External Email
> > > 
> > > ----------------------------------------------------------------------
> > > > -----Original Message-----
> > > > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > > Sent: Thursday, February 25, 2021 8:15 PM
> > > > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > > stable@dpdk.org
> > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > > > 
> > > > > -----Original Message-----
> > > > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > > > Sent: Saturday, February 20, 2021 9:13 AM
> > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> > > > > <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> > > > > <jerinj@marvell.com>
> > > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native
> > > > > machine args
> > > > > 
> > > > > External Email
> > > > > 
> > > > > ------------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > > -----Original Message-----
> > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > Sent: Friday, February 19, 2021 8:10 PM
> > > > > > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > > > > > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > > > > > david.marchand@redhat.com
> > > > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine
> > > > > > args
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Luca Boccassi <bluca@debian.org>
> > > > > > > Sent: Friday, February 19, 2021 12:33 PM
> > > > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > > > > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > david.marchand@redhat.com
> > > > > > > Subject: Re: [PATCH 20.11] config/arm: replace native machine
> > > > > > > args
> > > > > > > 
> > > > > > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > > > > > To: stable@dpdk.org
> > > > > > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > > > david.marchand@redhat.com
> > > > > > > > > Subject: [PATCH 20.11] config/arm: replace native machine
> > > > > > > > > args
> > > > > > > > > 
> > > > > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > > 
> > > > > > > > > [ backported from upstream commit
> > > > > > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > > > > > > 
> > > > > > > > > There are compiler issues when building with -mcpu=native
> > > > > > > > > with popular compilers, such as GCC-8.4:
> > > > > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > > > > ../lib/librte_net/net_crc_neon.c: In function
> > ‘crcr32_folding_round’:
> > > > > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1:
> > > > error:
> > > > > > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > > > > > target specific option mismatch
> > > > > > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > > > > > 
> > > > > > > > > and clang:
> > > > > > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > > __ARM_FEATURE_ATOMICS
> > > > > > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > > > > > > 
> > > > > > > > > Fix this by always specifying the proper machine args and
> > > > > > > > > never using the native flags.
> > > > > > > > > 
> > > > > > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > > > > > arguments")
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > > > > > ---
> > > > > > > > > This is a crude backport, but it fixes the build for arm64.
> > > > > > > > > It's a release blocker for 20.11.1, so I would appreciate
> > > > > > > > > a quick
> > > > review.
> > > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > What does this fix? With or without the below change, the
> > > > > > > > native machine
> > > > > > > args are not used. The patch shoudn't actually change the
> > > > > > > configuration of the build at all, so I'm a bit confused.
> > > > > > > 
> > > > > > > It fixes the build on some build workers with thunderx
> > > > > > > hardware
> > > > > > > - without this I get failures like:
> > > > > > > 
> > > > > > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > > > > > 'vmull_p64': target specific option mismatch
> > > > > > > 
> > > > > > 
> > > > > > I tried the patch and I'm seeing the same errors on a ThunderX
> > > > > > server (with and without the patch). Is this actually the right patch?
> > > > > > 
> > > > > > One of the four failures looks like this:
> > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > > > inlining failed in call to always_inline 'vmull_p64': target
> > > > > > specific option mismatch
> > > > > >  vmull_p64 (poly64_t a, poly64_t b)  ^~~~~~~~~
> > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > 
> > > > > > Ruifeng, any ideas on how to fix this?
> > > > > 
> > > > > Gcc build on ThunderX platform is broken. Issue can be seen in
> > > > > some
> > > > > CentOS-8 OBS builds.
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > > > 3A__mails.dpdk.org_archives_dev_2020-
> > > > > 
> > 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> > > > DG
> > ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKC
> > > > Uj
> > > > > 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> > > > > 1jKFC40Bh5hFanzu0A&e=
> > > > > I tried tuning compiler flags used, but could not resolve the issue.
> > > > > 
> > > > > Need help from Marvell to look at this.
> > > > > Hi Jerin, do you have any thoughts on this?
> > > > 
> > > > Ruifeng, If you are able to reproduce this issue, Could you add "-
> > > > march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
> > > > Fixing the issue?
> > > > 
> > > > [main] [dpdk.org] $ git diff
> > > > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > > > 00bc4610a..ef65b4bb6 100644
> > > > --- a/config/arm/meson.build
> > > > +++ b/config/arm/meson.build
> > > > @@ -96,15 +96,18 @@ implementer_cavium = {
> > > >         ],
> > > >         'part_number_config': {
> > > >                 '0xa1': {
> > > > -                       'machine_args': ['-mcpu=thunderxt88'],
> > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > +                                        '-mcpu=thunderxt88'],
> > > >                         'flags': flags_part_number_thunderx
> > > >                 },
> > > >                 '0xa2': {
> > > > -                       'machine_args': ['-mcpu=thunderxt81'],
> > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > +                                        '-mcpu=thunderxt81'],
> > > >                         'flags': flags_part_number_thunderx
> > > >                 },
> > > >                 '0xa3': {
> > > > -                       'machine_args': ['-mcpu=thunderxt83'],
> > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > +                                        '-mcpu=thunderxt83'],
> > > >                         'flags': flags_part_number_thunderx
> > > >                 },
> > > >                 '0xaf': {
> > > > 
> > > 
> > > Hi Jerin,
> > > 
> > > The patch doesn't work. Build failed at link stage.
> > > I used gcc 8.4 and tried build on thunderxt88.
> > 
> > 
> > Hi Ruifeng,
> > 
> > I talked to compiler experts here in Marvell. It looks like compiler issue, As a
> > workaround couple of these could try:
> > 1) Reduce the external libraries linked to the application like mlx5 etc
> 
> I tried building with lots of drivers disabled. Not yet able to get a successful build.
> 
> > 2) Add -mcmodel=large flag will fix "relocation truncated to fit" issue as
> > testing purpose as we are not sure about the implication of this flag.
> 
> Looks like this flag is not supported by gcc 8.4 that I am using.
> 
> One thing we can do to overcome the build failure is to switch to default / release build in OBS CI.
> OBS CI is running native build, so it could hit this issue when CI job is scheduled to thunderxt88 infrastructure.
> I think we should change to do release build (-Dmachine=default) which is more suitable for generic CI verification.
> As I checked, release build can pass on my thunderxt88 platform.
> 
> What do you think?

Hi,

I've done as suggested, and it seems to fare better, thank you.

There is still a build error on CentOS 7, not sure if it is related
though:

[  555s] ../drivers/event/octeontx2/otx2_tim_worker.c: In function 'otx2_tim_arm_tmo_tick_burst_mod':
[  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:154:18: error: could not split insn
[  555s]            struct rte_event_timer **tim, \
[  555s]                   ^
[  555s] ../drivers/event/octeontx2/otx2_tim_evdev.h:208:1: note: in expansion of macro 'FP'
[  555s]  FP(mod,   0, 0, 0, OTX2_TIM_BKT_MOD | OTX2_TIM_ENA_DFB)  \
[  555s]  ^
[  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:161:1: note: in expansion of macro 'TIM_ARM_TMO_FASTPATH_MODES'
[  555s]  TIM_ARM_TMO_FASTPATH_MODES
[  555s]  ^
[  555s] (insn 252 250 255 (parallel [
[  555s]             (set (reg:DI 1 x1 [orig:230 D.17092 ] [230])
[  555s]                 (mem/v:DI (reg/f:DI 10 x10 [orig:229 D.17094 ] [229]) [-1  S8 A64]))
[  555s]             (set (mem/v:DI (reg/f:DI 10 x10 [orig:229 D.17094 ] [229]) [-1  S8 A64])
[  555s]                 (unspec_volatile:DI [
[  555s]                         (plus:DI (mem/v:DI (reg/f:DI 10 x10 [orig:229 D.17094 ] [229]) [-1  S8 A64])
[  555s]                             (const_int 1099511627776 [0x10000000000]))
[  555s]                         (const_int 2 [0x2])
[  555s]                     ] UNSPECV_ATOMIC_OP))
[  555s]             (clobber (reg:CC 66 cc))
[  555s]             (clobber (reg:DI 4 x4))
[  555s]             (clobber (reg:SI 3 x3))
[  555s]         ]) ../drivers/event/octeontx2/otx2_tim_worker.h:81 1832 {atomic_fetch_adddi}
[  555s]      (expr_list:REG_UNUSED (reg:CC 66 cc)
[  555s]         (expr_list:REG_UNUSED (reg:DI 4 x4)
[  555s]             (expr_list:REG_UNUSED (reg:SI 3 x3)
[  555s]                 (nil)))))
[  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:154:18: internal compiler error: in final_scan_insn, at final.c:2897
[  555s]            struct rte_event_timer **tim, \
[  555s]                   ^
[  555s] ../drivers/event/octeontx2/otx2_tim_evdev.h:208:1: note: in expansion of macro 'FP'
[  555s]  FP(mod,   0, 0, 0, OTX2_TIM_BKT_MOD | OTX2_TIM_ENA_DFB)  \
[  555s]  ^
[  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:161:1: note: in expansion of macro 'TIM_ARM_TMO_FASTPATH_MODES'
[  555s]  TIM_ARM_TMO_FASTPATH_MODES
[  555s]  ^
[  555s] Please submit a full bug report,
[  555s] with preprocessed source if appropriate.
[  555s] See <http://bugzilla.redhat.com/bugzilla> for instructions.
[  555s] {standard input}: Assembler messages:
[  555s] {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
[  555s] Preprocessed source stored into /tmp/ccpVQUdT.out file, please attach this to your bugreport.

-- 
Kind regards,
Luca Boccassi

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [dpdk-dev] [PATCH 20.11] config/arm: replace native machine args
  2021-03-08  3:23               ` Ruifeng Wang
  2021-03-08 12:08                 ` Luca Boccassi
@ 2021-03-08 18:48                 ` Jerin Jacob
  1 sibling, 0 replies; 15+ messages in thread
From: Jerin Jacob @ 2021-03-08 18:48 UTC (permalink / raw)
  To: Ruifeng Wang
  Cc: jerinj, Juraj Linkeš,
	Luca Boccassi, stable, dev, thomas,
	Ashwin Sekhar Thalakalath Kottilveetil, Andrew Pinski,
	david.marchand, nd

On Mon, Mar 8, 2021 at 8:54 AM Ruifeng Wang <Ruifeng.Wang@arm.com> wrote:
>
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > Sent: Sunday, March 7, 2021 9:35 PM
> > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > stable@dpdk.org; dev@dpdk.org; thomas@monjalon.net; Ashwin Sekhar
> > Thalakalath Kottilveetil <asekhar@marvell.com>; Andrew Pinski
> > <apinski@marvell.com>
> > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> >
> >
> >
> > > -----Original Message-----
> > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > Sent: Monday, March 1, 2021 11:10 AM
> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj Linkeš
> > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > stable@dpdk.org
> > > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine
> > > args
> > >
> > > External Email
> > >
> > > ----------------------------------------------------------------------
> > > > -----Original Message-----
> > > > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > > Sent: Thursday, February 25, 2021 8:15 PM
> > > > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > > stable@dpdk.org
> > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > > >
> > > > > -----Original Message-----
> > > > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > > > Sent: Saturday, February 20, 2021 9:13 AM
> > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> > > > > <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> > > > > <jerinj@marvell.com>
> > > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native
> > > > > machine args
> > > > >
> > > > > External Email
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > > -----Original Message-----
> > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > Sent: Friday, February 19, 2021 8:10 PM
> > > > > > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > > > > > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > > > > > david.marchand@redhat.com
> > > > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine
> > > > > > args
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Luca Boccassi <bluca@debian.org>
> > > > > > > Sent: Friday, February 19, 2021 12:33 PM
> > > > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > > > > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > david.marchand@redhat.com
> > > > > > > Subject: Re: [PATCH 20.11] config/arm: replace native machine
> > > > > > > args
> > > > > > >
> > > > > > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > > > > > To: stable@dpdk.org
> > > > > > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > > > david.marchand@redhat.com
> > > > > > > > > Subject: [PATCH 20.11] config/arm: replace native machine
> > > > > > > > > args
> > > > > > > > >
> > > > > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > >
> > > > > > > > > [ backported from upstream commit
> > > > > > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > > > > > >
> > > > > > > > > There are compiler issues when building with -mcpu=native
> > > > > > > > > with popular compilers, such as GCC-8.4:
> > > > > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > > > > ../lib/librte_net/net_crc_neon.c: In function
> > ‘crcr32_folding_round’:
> > > > > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1:
> > > > error:
> > > > > > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > > > > > target specific option mismatch
> > > > > > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > > > > >
> > > > > > > > > and clang:
> > > > > > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > > __ARM_FEATURE_ATOMICS
> > > > > > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > > > > > >
> > > > > > > > > Fix this by always specifying the proper machine args and
> > > > > > > > > never using the native flags.
> > > > > > > > >
> > > > > > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > > > > > arguments")
> > > > > > > > >
> > > > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > > > > > ---
> > > > > > > > > This is a crude backport, but it fixes the build for arm64.
> > > > > > > > > It's a release blocker for 20.11.1, so I would appreciate
> > > > > > > > > a quick
> > > > review.
> > > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > What does this fix? With or without the below change, the
> > > > > > > > native machine
> > > > > > > args are not used. The patch shoudn't actually change the
> > > > > > > configuration of the build at all, so I'm a bit confused.
> > > > > > >
> > > > > > > It fixes the build on some build workers with thunderx
> > > > > > > hardware
> > > > > > > - without this I get failures like:
> > > > > > >
> > > > > > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > > > > > 'vmull_p64': target specific option mismatch
> > > > > > >
> > > > > >
> > > > > > I tried the patch and I'm seeing the same errors on a ThunderX
> > > > > > server (with and without the patch). Is this actually the right patch?
> > > > > >
> > > > > > One of the four failures looks like this:
> > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > > > inlining failed in call to always_inline 'vmull_p64': target
> > > > > > specific option mismatch
> > > > > >  vmull_p64 (poly64_t a, poly64_t b)  ^~~~~~~~~
> > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >
> > > > > > Ruifeng, any ideas on how to fix this?
> > > > >
> > > > > Gcc build on ThunderX platform is broken. Issue can be seen in
> > > > > some
> > > > > CentOS-8 OBS builds.
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > > > 3A__mails.dpdk.org_archives_dev_2020-
> > > > >
> > > >
> > 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> > > > DG
> > > > >
> > > >
> > ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKC
> > > > Uj
> > > > > 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> > > > > 1jKFC40Bh5hFanzu0A&e=
> > > > > I tried tuning compiler flags used, but could not resolve the issue.
> > > > >
> > > > > Need help from Marvell to look at this.
> > > > > Hi Jerin, do you have any thoughts on this?
> > > >
> > > >
> > > > Ruifeng, If you are able to reproduce this issue, Could you add "-
> > > > march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
> > > > Fixing the issue?
> > > >
> > > > [main] [dpdk.org] $ git diff
> > > > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > > > 00bc4610a..ef65b4bb6 100644
> > > > --- a/config/arm/meson.build
> > > > +++ b/config/arm/meson.build
> > > > @@ -96,15 +96,18 @@ implementer_cavium = {
> > > >         ],
> > > >         'part_number_config': {
> > > >                 '0xa1': {
> > > > -                       'machine_args': ['-mcpu=thunderxt88'],
> > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > +                                        '-mcpu=thunderxt88'],
> > > >                         'flags': flags_part_number_thunderx
> > > >                 },
> > > >                 '0xa2': {
> > > > -                       'machine_args': ['-mcpu=thunderxt81'],
> > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > +                                        '-mcpu=thunderxt81'],
> > > >                         'flags': flags_part_number_thunderx
> > > >                 },
> > > >                 '0xa3': {
> > > > -                       'machine_args': ['-mcpu=thunderxt83'],
> > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > +                                        '-mcpu=thunderxt83'],
> > > >                         'flags': flags_part_number_thunderx
> > > >                 },
> > > >                 '0xaf': {
> > > >
> > >
> > > Hi Jerin,
> > >
> > > The patch doesn't work. Build failed at link stage.
> > > I used gcc 8.4 and tried build on thunderxt88.
> >
> >
> >
> > Hi Ruifeng,
> >
> > I talked to compiler experts here in Marvell. It looks like compiler issue, As a
> > workaround couple of these could try:
> > 1) Reduce the external libraries linked to the application like mlx5 etc
>
> I tried building with lots of drivers disabled. Not yet able to get a successful build.
>
> > 2) Add -mcmodel=large flag will fix "relocation truncated to fit" issue as
> > testing purpose as we are not sure about the implication of this flag.
>
> Looks like this flag is not supported by gcc 8.4 that I am using.
>
> One thing we can do to overcome the build failure is to switch to default / release build in OBS CI.
> OBS CI is running native build, so it could hit this issue when CI job is scheduled to thunderxt88 infrastructure.
> I think we should change to do release build (-Dmachine=default) which is more suitable for generic CI verification.
> As I checked, release build can pass on my thunderxt88 platform.
>
> What do you think?

Sounds good to me.

> >
> >
> > >
> > > Logs as below:
> > > [2513/2527] Linking target app/test/dpdk-test
> > > FAILED: app/test/dpdk-test
> > > cc  -o app/test/dpdk-test app/test/dpdk-test.p/commands.c.o
> > > app/test/dpdk- test.p/packet_burst_generator.c.o
> > > app/test/dpdk-test.p/test.c.o app/test/dpdk- test.p/test_acl.c.o
> > > app/test/dpdk-test.p/test_alarm.c.o app/test/dpdk-
> > > test.p/test_atomic.c.o app/test/dpdk-test.p/test_barrier.c.o
> > > app/test/dpdk- test.p/test_bitops.c.o
> > > app/test/dpdk-test.p/test_bitmap.c.o app/test/dpdk-
> > > test.p/test_bpf.c.o app/test/dpdk-test.p/test_byteorder.c.o
> > > app/test/dpdk- test.p/test_cmdline.c.o
> > > app/test/dpdk-test.p/test_cmdline_cirbuf.c.o
> > > app/test/dpdk-test.p/test_cmdline_etheraddr.c.o app/test/dpdk-
> > > test.p/test_cmdline_ipaddr.c.o
> > > app/test/dpdk-test.p/test_cmdline_lib.c.o
> > > app/test/dpdk-test.p/test_cmdline_num.c.o app/test/dpdk-
> > > test.p/test_cmdline_portlist.c.o
> > > app/test/dpdk-test.p/test_cmdline_string.c.o
> > > app/test/dpdk-test.p/test_common.c.o
> > > app/test/dpdk-test.p/test_cpuflags.c.o
> > > app/test/dpdk-test.p/test_crc.c.o
> > > app/test/dpdk-test.p/test_cryptodev.c.o
> > > app/test/dpdk-test.p/test_cryptodev_asym.c.o app/test/dpdk-
> > > test.p/test_cryptodev_blockcipher.c.o app/test/dpdk-
> > > test.p/test_cryptodev_security_pdcp.c.o
> > > app/test/dpdk-test.p/test_cycles.c.o
> > > app/test/dpdk-test.p/test_debug.c.o
> > > app/test/dpdk-test.p/test_distributor.c.o
> > > app/test/dpdk-test.p/test_distributor_perf.c.o app/test/dpdk-
> > > test.p/test_eal_flags.c.o app/test/dpdk-test.p/test_eal_fs.c.o
> > > app/test/dpdk- test.p/test_efd.c.o
> > > app/test/dpdk-test.p/test_efd_perf.c.o app/test/dpdk-
> > > test.p/test_errno.c.o app/test/dpdk-test.p/test_ethdev_link.c.o
> > > app/test/dpdk- test.p/test_event_crypto_adapter.c.o app/test/dpdk-
> > > test.p/test_event_eth_rx_adapter.c.o
> > > app/test/dpdk-test.p/test_event_ring.c.o
> > > app/test/dpdk-test.p/test_event_timer_adapter.c.o app/test/dpdk-
> > > test.p/test_eventdev.c.o app/test/dpdk-test.p/test_external_mem.c.o
> > > app/test/dpdk-test.p/test_fbarray.c.o
> > > app/test/dpdk-test.p/test_fib.c.o
> > > app/test/dpdk-test.p/test_fib_perf.c.o
> > > app/test/dpdk-test.p/test_fib6.c.o
> > > app/test/dpdk-test.p/test_fib6_perf.c.o app/test/dpdk-
> > > test.p/test_func_reentrancy.c.o
> > > app/test/dpdk-test.p/test_flow_classify.c.o
> > > app/test/dpdk-test.p/test_graph.c.o
> > > app/test/dpdk-test.p/test_graph_perf.c.o
> > > app/test/dpdk-test.p/test_hash.c.o app/test/dpdk-
> > > test.p/test_hash_functions.c.o
> > > app/test/dpdk-test.p/test_hash_multiwriter.c.o
> > > app/test/dpdk-test.p/test_hash_readwrite.c.o app/test/dpdk-
> > > test.p/test_hash_perf.c.o
> > > app/test/dpdk-test.p/test_hash_readwrite_lf_perf.c.o
> > > app/test/dpdk-test.p/test_interrupts.c.o
> > > app/test/dpdk-test.p/test_ipfrag.c.o
> > > app/test/dpdk-test.p/test_ipsec.c.o
> > > app/test/dpdk-test.p/test_ipsec_sad.c.o
> > > app/test/dpdk-test.p/test_ipsec_perf.c.o
> > > app/test/dpdk-test.p/test_kni.c.o app/test/dpdk-test.p/test_kvargs.c.o
> > > app/test/dpdk-test.p/test_lcores.c.o
> > > app/test/dpdk-test.p/test_logs.c.o app/test/dpdk-test.p/test_lpm.c.o
> > > app/test/dpdk-test.p/test_lpm6.c.o
> > > app/test/dpdk-test.p/test_lpm6_perf.c.o
> > > app/test/dpdk-test.p/test_lpm_perf.c.o
> > > app/test/dpdk-test.p/test_malloc.c.o
> > > app/test/dpdk-test.p/test_mbuf.c.o
> > > app/test/dpdk-test.p/test_member.c.o
> > > app/test/dpdk-test.p/test_member_perf.c.o app/test/dpdk-
> > > test.p/test_memcpy.c.o app/test/dpdk-test.p/test_memcpy_perf.c.o
> > > app/test/dpdk-test.p/test_memory.c.o
> > > app/test/dpdk-test.p/test_mempool.c.o
> > > app/test/dpdk-test.p/test_mempool_perf.c.o app/test/dpdk-
> > > test.p/test_memzone.c.o app/test/dpdk-test.p/test_meter.c.o
> > > app/test/dpdk- test.p/test_metrics.c.o
> > > app/test/dpdk-test.p/test_mcslock.c.o app/test/dpdk-
> > > test.p/test_mp_secondary.c.o app/test/dpdk-test.p/test_per_lcore.c.o
> > > app/test/dpdk-test.p/test_pmd_perf.c.o
> > > app/test/dpdk-test.p/test_power.c.o
> > > app/test/dpdk-test.p/test_power_cpufreq.c.o app/test/dpdk-
> > > test.p/test_power_kvm_vm.c.o app/test/dpdk-test.p/test_prefetch.c.o
> > > app/test/dpdk-test.p/test_rand_perf.c.o
> > > app/test/dpdk-test.p/test_rawdev.c.o
> > > app/test/dpdk-test.p/test_rcu_qsbr.c.o app/test/dpdk-
> > > test.p/test_rcu_qsbr_perf.c.o
> > > app/test/dpdk-test.p/test_reciprocal_division.c.o
> > > app/test/dpdk-test.p/test_reciprocal_division_perf.c.o app/test/dpdk-
> > > test.p/test_red.c.o app/test/dpdk-test.p/test_reorder.c.o
> > > app/test/dpdk- test.p/test_rib.c.o app/test/dpdk-test.p/test_rib6.c.o
> > > app/test/dpdk- test.p/test_ring.c.o
> > > app/test/dpdk-test.p/test_ring_mpmc_stress.c.o
> > > app/test/dpdk-test.p/test_ring_hts_stress.c.o app/test/dpdk-
> > > test.p/test_ring_mt_peek_stress.c.o app/test/dpdk-
> > > test.p/test_ring_mt_peek_stress_zc.c.o
> > > app/test/dpdk-test.p/test_ring_perf.c.o
> > > app/test/dpdk-test.p/test_ring_rts_stress.c.o app/test/dpdk-
> > > test.p/test_ring_st_peek_stress.c.o app/test/dpdk-
> > > test.p/test_ring_st_peek_stress_zc.c.o
> > > app/test/dpdk-test.p/test_ring_stress.c.o
> > > app/test/dpdk-test.p/test_rwlock.c.o
> > > app/test/dpdk-test.p/test_sched.c.o
> > > app/test/dpdk-test.p/test_security.c.o app/test/dpdk-
> > > test.p/test_service_cores.c.o app/test/dpdk-test.p/test_spinlock.c.o
> > > app/test/dpdk-test.p/test_stack.c.o
> > > app/test/dpdk-test.p/test_stack_perf.c.o
> > > app/test/dpdk-test.p/test_string_fns.c.o
> > > app/test/dpdk-test.p/test_table.c.o
> > > app/test/dpdk-test.p/test_table_acl.c.o app/test/dpdk-
> > > test.p/test_table_combined.c.o
> > > app/test/dpdk-test.p/test_table_pipeline.c.o
> > > app/test/dpdk-test.p/test_table_ports.c.o app/test/dpdk-
> > > test.p/test_table_tables.c.o app/test/dpdk-test.p/test_tailq.c.o
> > > app/test/dpdk- test.p/test_thash.c.o
> > > app/test/dpdk-test.p/test_timer.c.o app/test/dpdk-
> > > test.p/test_timer_perf.c.o
> > > app/test/dpdk-test.p/test_timer_racecond.c.o
> > > app/test/dpdk-test.p/test_timer_secondary.c.o app/test/dpdk-
> > > test.p/test_ticketlock.c.o app/test/dpdk-test.p/test_trace.c.o
> > > app/test/dpdk- test.p/test_trace_register.c.o
> > > app/test/dpdk-test.p/test_trace_perf.c.o
> > > app/test/dpdk-test.p/test_version.c.o
> > > app/test/dpdk-test.p/virtual_pmd.c.o
> > > app/test/dpdk-test.p/test_telemetry_json.c.o app/test/dpdk-
> > > test.p/test_telemetry_data.c.o
> > > app/test/dpdk-test.p/test_link_bonding.c.o
> > > app/test/dpdk-test.p/test_link_bonding_rssconf.c.o app/test/dpdk-
> > > test.p/test_link_bonding_mode4.c.o app/test/dpdk-
> > > test.p/test_pmd_ring_perf.c.o app/test/dpdk-test.p/test_pmd_ring.c.o
> > > app/test/dpdk-test.p/test_event_eth_tx_adapter.c.o app/test/dpdk-
> > > test.p/test_bitratestats.c.o
> > > app/test/dpdk-test.p/test_latencystats.c.o
> > > app/test/dpdk-test.p/sample_packet_forward.c.o app/test/dpdk-
> > > test.p/test_pdump.c.o app/test/dpdk-test.p/test_compressdev.c.o
> > > -Wl,--as- needed -Wl,--no-undefined -Wl,-O1 -Wl,--whole-archive
> > > -Wl,--start-group lib/librte_node.a lib/librte_graph.a
> > > lib/librte_bpf.a lib/librte_flow_classify.a lib/librte_pipeline.a
> > > lib/librte_table.a lib/librte_port.a lib/librte_fib.a
> > > lib/librte_ipsec.a lib/librte_vhost.a lib/librte_stack.a
> > > lib/librte_security.a lib/librte_sched.a lib/librte_reorder.a
> > > lib/librte_rib.a lib/librte_regexdev.a lib/librte_rawdev.a
> > > lib/librte_pdump.a lib/librte_power.a lib/librte_member.a
> > > lib/librte_lpm.a lib/librte_latencystats.a lib/librte_kni.a
> > > lib/librte_jobstats.a lib/librte_ip_frag.a lib/librte_gso.a
> > > lib/librte_gro.a lib/librte_eventdev.a lib/librte_efd.a
> > > lib/librte_distributor.a lib/librte_cryptodev.a
> > > lib/librte_compressdev.a lib/librte_cfgfile.a
> > > lib/librte_bitratestats.a lib/librte_bbdev.a lib/librte_acl.a
> > > lib/librte_timer.a lib/librte_hash.a lib/librte_metrics.a
> > > lib/librte_cmdline.a lib/librte_pci.a lib/librte_ethdev.a
> > > lib/librte_meter.a lib/librte_net.a lib/librte_mbuf.a
> > > lib/librte_mempool.a lib/librte_rcu.a lib/librte_ring.a
> > > lib/librte_eal.a lib/librte_telemetry.a lib/librte_kvargs.a
> > > drivers/librte_common_cpt.a drivers/librte_common_dpaax.a
> > > drivers/librte_common_iavf.a drivers/librte_common_octeontx.a
> > > drivers/librte_common_octeontx2.a drivers/librte_common_sfc_efx.a
> > > drivers/librte_bus_dpaa.a drivers/librte_bus_fslmc.a
> > > drivers/librte_bus_ifpga.a drivers/librte_bus_pci.a
> > > drivers/librte_bus_vdev.a drivers/librte_bus_vmbus.a
> > > drivers/librte_common_mlx5.a drivers/librte_common_qat.a
> > > drivers/librte_mempool_bucket.a drivers/librte_mempool_dpaa.a
> > > drivers/librte_mempool_dpaa2.a drivers/librte_mempool_octeontx.a
> > > drivers/librte_mempool_octeontx2.a drivers/librte_mempool_ring.a
> > > drivers/librte_mempool_stack.a drivers/librte_net_af_packet.a
> > > drivers/librte_net_ark.a drivers/librte_net_atlantic.a
> > > drivers/librte_net_avp.a drivers/librte_net_axgbe.a
> > > drivers/librte_net_bond.a drivers/librte_net_bnx2x.a
> > > drivers/librte_net_bnxt.a drivers/librte_net_cxgbe.a
> > > drivers/librte_net_dpaa.a drivers/librte_net_dpaa2.a
> > > drivers/librte_net_e1000.a drivers/librte_net_ena.a
> > > drivers/librte_net_enetc.a drivers/librte_net_enic.a
> > > drivers/librte_net_failsafe.a drivers/librte_net_fm10k.a
> > > drivers/librte_net_i40e.a drivers/librte_net_hinic.a
> > > drivers/librte_net_hns3.a drivers/librte_net_iavf.a
> > > drivers/librte_net_ice.a drivers/librte_net_igc.a
> > > drivers/librte_net_ionic.a drivers/librte_net_ixgbe.a
> > > drivers/librte_net_kni.a drivers/librte_net_liquidio.a
> > > drivers/librte_net_memif.a drivers/librte_net_mlx4.a
> > > drivers/librte_net_mlx5.a drivers/librte_net_netvsc.a
> > > drivers/librte_net_nfp.a drivers/librte_net_null.a
> > > drivers/librte_net_octeontx.a drivers/librte_net_octeontx2.a
> > > drivers/librte_net_octeontx_ep.a drivers/librte_net_pfe.a
> > > drivers/librte_net_qede.a drivers/librte_net_ring.a
> > > drivers/librte_net_sfc.a drivers/librte_net_softnic.a
> > > drivers/librte_net_tap.a drivers/librte_net_thunderx.a
> > > drivers/librte_net_txgbe.a drivers/librte_net_vdev_netvsc.a
> > > drivers/librte_net_vhost.a drivers/librte_net_virtio.a
> > > drivers/librte_net_vmxnet3.a drivers/librte_raw_dpaa2_cmdif.a
> > > drivers/librte_raw_dpaa2_qdma.a drivers/librte_raw_ntb.a
> > > drivers/librte_raw_octeontx2_dma.a
> > > drivers/librte_raw_octeontx2_ep.a drivers/librte_raw_skeleton.a
> > > drivers/librte_crypto_bcmfs.a drivers/librte_crypto_caam_jr.a
> > > drivers/librte_crypto_ccp.a drivers/librte_crypto_dpaa_sec.a
> > > drivers/librte_crypto_dpaa2_sec.a drivers/librte_crypto_nitrox.a
> > > drivers/librte_crypto_null.a drivers/librte_crypto_octeontx.a
> > > drivers/librte_crypto_octeontx2.a drivers/librte_crypto_openssl.a
> > > drivers/librte_crypto_scheduler.a drivers/librte_crypto_virtio.a
> > > drivers/librte_compress_mlx5.a drivers/librte_compress_octeontx.a
> > > drivers/librte_compress_zlib.a drivers/librte_regex_mlx5.a
> > > drivers/librte_regex_octeontx2.a drivers/librte_vdpa_ifc.a
> > > drivers/librte_vdpa_mlx5.a drivers/librte_event_dpaa.a
> > > drivers/librte_event_dpaa2.a drivers/librte_event_octeontx2.a
> > > drivers/librte_event_opdl.a drivers/librte_event_skeleton.a
> > > drivers/librte_event_sw.a drivers/librte_event_dsw.a
> > > drivers/librte_event_octeontx.a drivers/librte_baseband_null.a
> > > drivers/librte_baseband_turbo_sw.a
> > > drivers/librte_baseband_fpga_lte_fec.a
> > > drivers/librte_baseband_fpga_5gnr_fec.a
> > > drivers/librte_baseband_acc100.a - Wl,--no-whole-archive
> > > -Wl,--no-as-needed -pthread -lm -ldl -lnuma
> > > /usr/lib/aarch64-linux-gnu/libz.so -lmlx5 -libverbs
> > > /usr/lib/aarch64-linux- gnu/libcrypto.so -lmlx4 -libverbs -lmlx5
> > > -libverbs -lmlx5 -libverbs -lmlx5 - libverbs -lmlx5 -libverbs
> > > -Wl,--end-group -Wl,-
> > > rpath,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > > app/test/dpdk-test.p/test_hash_perf.c.o: In function `test_hash_perf':
> > > test_hash_perf.c:(.text+0x1c74): relocation truncated to fit:
> > > R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> > > test_hash_perf.c:(.text+0x1d8c): relocation truncated to fit:
> > > R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> > > test_hash_perf.c:(.text+0x2508): relocation truncated to fit:
> > > R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
> > > collect2: error: ld returned 1 exit status [2527/2527] Linking target
> > > app/dpdk- test-bbdev
> > > ninja: build stopped: subcommand failed.
> > >
> > > > > >
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Luca Boccassi
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-stable] [dpdk-dev] [PATCH 20.11] config/arm: replace native machine args
  2021-03-08 12:08                 ` Luca Boccassi
@ 2021-03-08 18:51                   ` Jerin Jacob
  0 siblings, 0 replies; 15+ messages in thread
From: Jerin Jacob @ 2021-03-08 18:51 UTC (permalink / raw)
  To: Luca Boccassi
  Cc: Ruifeng Wang, jerinj, Juraj Linkeš,
	stable, dev, thomas, Ashwin Sekhar Thalakalath Kottilveetil,
	Andrew Pinski, david.marchand, nd

On Mon, Mar 8, 2021 at 5:38 PM Luca Boccassi <bluca@debian.org> wrote:
>
> On Mon, 2021-03-08 at 03:23 +0000, Ruifeng Wang wrote:
> > > -----Original Message-----
> > > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > Sent: Sunday, March 7, 2021 9:35 PM
> > > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > stable@dpdk.org; dev@dpdk.org; thomas@monjalon.net; Ashwin Sekhar
> > > Thalakalath Kottilveetil <asekhar@marvell.com>; Andrew Pinski
> > > <apinski@marvell.com>
> > > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > > Sent: Monday, March 1, 2021 11:10 AM
> > > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Juraj Linkeš
> > > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > > stable@dpdk.org
> > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>; nd <nd@arm.com>
> > > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native machine
> > > > args
> > > >
> > > > External Email
> > > >
> > > > ----------------------------------------------------------------------
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > > > Sent: Thursday, February 25, 2021 8:15 PM
> > > > > To: Ruifeng Wang <Ruifeng.Wang@arm.com>; Juraj Linkeš
> > > > > <juraj.linkes@pantheon.tech>; Luca Boccassi <bluca@debian.org>;
> > > > > stable@dpdk.org
> > > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine args
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ruifeng Wang <Ruifeng.Wang@arm.com>
> > > > > > Sent: Saturday, February 20, 2021 9:13 AM
> > > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; Luca Boccassi
> > > > > > <bluca@debian.org>; stable@dpdk.org; Jerin Jacob Kollanukkaran
> > > > > > <jerinj@marvell.com>
> > > > > > Cc: david.marchand@redhat.com; nd <nd@arm.com>
> > > > > > Subject: [EXT] RE: [PATCH 20.11] config/arm: replace native
> > > > > > machine args
> > > > > >
> > > > > > External Email
> > > > > >
> > > > > > ------------------------------------------------------------------
> > > > > > --
> > > > > > --
> > > > > > > -----Original Message-----
> > > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > Sent: Friday, February 19, 2021 8:10 PM
> > > > > > > To: Luca Boccassi <bluca@debian.org>; stable@dpdk.org
> > > > > > > Cc: jerinj@marvell.com; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> > > > > > > david.marchand@redhat.com
> > > > > > > Subject: RE: [PATCH 20.11] config/arm: replace native machine
> > > > > > > args
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Luca Boccassi <bluca@debian.org>
> > > > > > > > Sent: Friday, February 19, 2021 12:33 PM
> > > > > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>; stable@dpdk.org
> > > > > > > > Cc: jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > > david.marchand@redhat.com
> > > > > > > > Subject: Re: [PATCH 20.11] config/arm: replace native machine
> > > > > > > > args
> > > > > > > >
> > > > > > > > On Fri, 2021-02-19 at 11:06 +0000, Juraj Linkeš wrote:
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: luca.boccassi@gmail.com <luca.boccassi@gmail.com>
> > > > > > > > > > Sent: Friday, February 19, 2021 11:58 AM
> > > > > > > > > > To: stable@dpdk.org
> > > > > > > > > > Cc: Juraj Linkeš <juraj.linkes@pantheon.tech>;
> > > > > > > > > > jerinj@marvell.com; ruifeng.wang@arm.com;
> > > > > > > > > > david.marchand@redhat.com
> > > > > > > > > > Subject: [PATCH 20.11] config/arm: replace native machine
> > > > > > > > > > args
> > > > > > > > > >
> > > > > > > > > > From: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > > >
> > > > > > > > > > [ backported from upstream commit
> > > > > > > > > > 9186e5a07f35ae74a1f7fa2d89671b5f77eae407 ]
> > > > > > > > > >
> > > > > > > > > > There are compiler issues when building with -mcpu=native
> > > > > > > > > > with popular compilers, such as GCC-8.4:
> > > > > > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > > > > > ../lib/librte_net/net_crc_neon.c: In function
> > > ‘crcr32_folding_round’:
> > > > > > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1:
> > > > > error:
> > > > > > > > > > inlining failed in call to always_inline ‘vmull_p64’:
> > > > > > > > > > target specific option mismatch
> > > > > > > > > >  vmull_p64 (poly64_t a, poly64_t b)
> > > > > > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > > > > > >
> > > > > > > > > > and clang:
> > > > > > > > > > gcc -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > > > __ARM_FEATURE_ATOMICS
> > > > > > > > > > clang-9 -E -dM -mcpu="native" - < /dev/null | grep
> > > > > > > > > > __ARM_FEATURE_ATOMICS <no output> # no clang support
> > > > > > > > > >
> > > > > > > > > > Fix this by always specifying the proper machine args and
> > > > > > > > > > never using the native flags.
> > > > > > > > > >
> > > > > > > > > > Fixes: 78ac8eac7e8a ("config/arm: use native machine build
> > > > > > > > > > arguments")
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > > > Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > > > > > > > > ---
> > > > > > > > > > This is a crude backport, but it fixes the build for arm64.
> > > > > > > > > > It's a release blocker for 20.11.1, so I would appreciate
> > > > > > > > > > a quick
> > > > > review.
> > > > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > What does this fix? With or without the below change, the
> > > > > > > > > native machine
> > > > > > > > args are not used. The patch shoudn't actually change the
> > > > > > > > configuration of the build at all, so I'm a bit confused.
> > > > > > > >
> > > > > > > > It fixes the build on some build workers with thunderx
> > > > > > > > hardware
> > > > > > > > - without this I get failures like:
> > > > > > > >
> > > > > > > > arm_neon.h:26647:1: error: inlining failed in call to 'always_inline'
> > > > > > > > 'vmull_p64': target specific option mismatch
> > > > > > > >
> > > > > > >
> > > > > > > I tried the patch and I'm seeing the same errors on a ThunderX
> > > > > > > server (with and without the patch). Is this actually the right patch?
> > > > > > >
> > > > > > > One of the four failures looks like this:
> > > > > > > In file included from ../lib/librte_eal/arm/include/rte_vect.h:11,
> > > > > > >                  from ../lib/librte_net/net_crc_neon.c:10:
> > > > > > > ../lib/librte_net/net_crc_neon.c: In function 'crcr32_folding_round':
> > > > > > > /usr/lib/gcc/aarch64-linux-gnu/8/include/arm_neon.h:26094:1: error:
> > > > > > > inlining failed in call to always_inline 'vmull_p64': target
> > > > > > > specific option mismatch
> > > > > > >  vmull_p64 (poly64_t a, poly64_t b)  ^~~~~~~~~
> > > > > > > ../lib/librte_net/net_crc_neon.c:50:20: note: called from here
> > > > > > >   uint64x2_t tmp1 = vreinterpretq_u64_p128(vmull_p64(
> > > > > > >                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(fold), 0),
> > > > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > >     vgetq_lane_p64(vreinterpretq_p64_u64(precomp), 1)));
> > > > > > >     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > >
> > > > > > > Ruifeng, any ideas on how to fix this?
> > > > > >
> > > > > > Gcc build on ThunderX platform is broken. Issue can be seen in
> > > > > > some
> > > > > > CentOS-8 OBS builds.
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > > > > 3A__mails.dpdk.org_archives_dev_2020-
> > > > > >
> > > 2DNovember_192909.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=1
> > > > > DG
> > > ob4H4rxz6H8uITozGOCa0s5f4wCNtTa4UUKvcsvI&m=mgzJ6z43dsDFwI6rdgKC
> > > > > Uj
> > > > > > 0GCMNjEKQAa7dfRZxvrdU&s=UWUJTFdGC2mD2x-rcuRnH1I7-
> > > > > > 1jKFC40Bh5hFanzu0A&e=
> > > > > > I tried tuning compiler flags used, but could not resolve the issue.
> > > > > >
> > > > > > Need help from Marvell to look at this.
> > > > > > Hi Jerin, do you have any thoughts on this?
> > > > >
> > > > > Ruifeng, If you are able to reproduce this issue, Could you add "-
> > > > > march=armv8.1-a+crc+crypto" In ThunderX config  and check is this
> > > > > Fixing the issue?
> > > > >
> > > > > [main] [dpdk.org] $ git diff
> > > > > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > > > > 00bc4610a..ef65b4bb6 100644
> > > > > --- a/config/arm/meson.build
> > > > > +++ b/config/arm/meson.build
> > > > > @@ -96,15 +96,18 @@ implementer_cavium = {
> > > > >         ],
> > > > >         'part_number_config': {
> > > > >                 '0xa1': {
> > > > > -                       'machine_args': ['-mcpu=thunderxt88'],
> > > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > > +                                        '-mcpu=thunderxt88'],
> > > > >                         'flags': flags_part_number_thunderx
> > > > >                 },
> > > > >                 '0xa2': {
> > > > > -                       'machine_args': ['-mcpu=thunderxt81'],
> > > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > > +                                        '-mcpu=thunderxt81'],
> > > > >                         'flags': flags_part_number_thunderx
> > > > >                 },
> > > > >                 '0xa3': {
> > > > > -                       'machine_args': ['-mcpu=thunderxt83'],
> > > > > +                       'machine_args': ['-march=armv8.1-a+crc+crypto+lse',
> > > > > +                                        '-mcpu=thunderxt83'],
> > > > >                         'flags': flags_part_number_thunderx
> > > > >                 },
> > > > >                 '0xaf': {
> > > > >
> > > >
> > > > Hi Jerin,
> > > >
> > > > The patch doesn't work. Build failed at link stage.
> > > > I used gcc 8.4 and tried build on thunderxt88.
> > >
> > >
> > > Hi Ruifeng,
> > >
> > > I talked to compiler experts here in Marvell. It looks like compiler issue, As a
> > > workaround couple of these could try:
> > > 1) Reduce the external libraries linked to the application like mlx5 etc
> >
> > I tried building with lots of drivers disabled. Not yet able to get a successful build.
> >
> > > 2) Add -mcmodel=large flag will fix "relocation truncated to fit" issue as
> > > testing purpose as we are not sure about the implication of this flag.
> >
> > Looks like this flag is not supported by gcc 8.4 that I am using.
> >
> > One thing we can do to overcome the build failure is to switch to default / release build in OBS CI.
> > OBS CI is running native build, so it could hit this issue when CI job is scheduled to thunderxt88 infrastructure.
> > I think we should change to do release build (-Dmachine=default) which is more suitable for generic CI verification.
> > As I checked, release build can pass on my thunderxt88 platform.
> >
> > What do you think?
>
> Hi,
>
> I've done as suggested, and it seems to fare better, thank you.
>
> There is still a build error on CentOS 7, not sure if it is related


That ICE is a known issue from the compiler. Please use gcc 4.8 at
least for arm64 work.
Similar issue[1] present in some 5.2.1, 6.0 version too.

[1]
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67143


> though:
>
> [  555s] ../drivers/event/octeontx2/otx2_tim_worker.c: In function 'otx2_tim_arm_tmo_tick_burst_mod':
> [  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:154:18: error: could not split insn
> [  555s]            struct rte_event_timer **tim, \
> [  555s]                   ^
> [  555s] ../drivers/event/octeontx2/otx2_tim_evdev.h:208:1: note: in expansion of macro 'FP'
> [  555s]  FP(mod,   0, 0, 0, OTX2_TIM_BKT_MOD | OTX2_TIM_ENA_DFB)  \
> [  555s]  ^
> [  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:161:1: note: in expansion of macro 'TIM_ARM_TMO_FASTPATH_MODES'
> [  555s]  TIM_ARM_TMO_FASTPATH_MODES
> [  555s]  ^
> [  555s] (insn 252 250 255 (parallel [
> [  555s]             (set (reg:DI 1 x1 [orig:230 D.17092 ] [230])
> [  555s]                 (mem/v:DI (reg/f:DI 10 x10 [orig:229 D.17094 ] [229]) [-1  S8 A64]))
> [  555s]             (set (mem/v:DI (reg/f:DI 10 x10 [orig:229 D.17094 ] [229]) [-1  S8 A64])
> [  555s]                 (unspec_volatile:DI [
> [  555s]                         (plus:DI (mem/v:DI (reg/f:DI 10 x10 [orig:229 D.17094 ] [229]) [-1  S8 A64])
> [  555s]                             (const_int 1099511627776 [0x10000000000]))
> [  555s]                         (const_int 2 [0x2])
> [  555s]                     ] UNSPECV_ATOMIC_OP))
> [  555s]             (clobber (reg:CC 66 cc))
> [  555s]             (clobber (reg:DI 4 x4))
> [  555s]             (clobber (reg:SI 3 x3))
> [  555s]         ]) ../drivers/event/octeontx2/otx2_tim_worker.h:81 1832 {atomic_fetch_adddi}
> [  555s]      (expr_list:REG_UNUSED (reg:CC 66 cc)
> [  555s]         (expr_list:REG_UNUSED (reg:DI 4 x4)
> [  555s]             (expr_list:REG_UNUSED (reg:SI 3 x3)
> [  555s]                 (nil)))))
> [  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:154:18: internal compiler error: in final_scan_insn, at final.c:2897
> [  555s]            struct rte_event_timer **tim, \
> [  555s]                   ^
> [  555s] ../drivers/event/octeontx2/otx2_tim_evdev.h:208:1: note: in expansion of macro 'FP'
> [  555s]  FP(mod,   0, 0, 0, OTX2_TIM_BKT_MOD | OTX2_TIM_ENA_DFB)  \
> [  555s]  ^
> [  555s] ../drivers/event/octeontx2/otx2_tim_worker.c:161:1: note: in expansion of macro 'TIM_ARM_TMO_FASTPATH_MODES'
> [  555s]  TIM_ARM_TMO_FASTPATH_MODES
> [  555s]  ^
> [  555s] Please submit a full bug report,
> [  555s] with preprocessed source if appropriate.
> [  555s] See <http://bugzilla.redhat.com/bugzilla> for instructions.
> [  555s] {standard input}: Assembler messages:
> [  555s] {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
> [  555s] Preprocessed source stored into /tmp/ccpVQUdT.out file, please attach this to your bugreport.
>
> --
> Kind regards,
> Luca Boccassi

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-03-08 18:51 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-19 10:57 [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args luca.boccassi
2021-02-19 11:06 ` Juraj Linkeš
2021-02-19 11:33   ` Luca Boccassi
2021-02-19 12:10     ` Juraj Linkeš
2021-02-19 13:04       ` Luca Boccassi
2021-02-24 12:51         ` Juraj Linkeš
2021-02-20  3:42       ` Ruifeng Wang
2021-02-25 12:14         ` Jerin Jacob Kollanukkaran
2021-02-25 14:24           ` David Marchand
2021-03-01  5:40           ` Ruifeng Wang
2021-03-07 13:35             ` Jerin Jacob Kollanukkaran
2021-03-08  3:23               ` Ruifeng Wang
2021-03-08 12:08                 ` Luca Boccassi
2021-03-08 18:51                   ` [dpdk-stable] [dpdk-dev] " Jerin Jacob
2021-03-08 18:48                 ` Jerin Jacob

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).