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
> -----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 >
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
> -----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
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
> -----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
> -----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
> -----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
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
> -----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
> -----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
> -----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
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
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 >
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