patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
To: Luca Boccassi <bluca@debian.org>, "stable@dpdk.org" <stable@dpdk.org>
Cc: "jerinj@marvell.com" <jerinj@marvell.com>,
	"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>
Subject: Re: [dpdk-stable] [PATCH 20.11] config/arm: replace native machine args
Date: Wed, 24 Feb 2021 12:51:58 +0000	[thread overview]
Message-ID: <899bb05e35724b3e93802298c35906a1@pantheon.tech> (raw)
In-Reply-To: <9052e36bcefd1d82677bad5e54c4b621ad08c0fe.camel@debian.org>



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


  reply	other threads:[~2021-02-24 12:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 10:57 luca.boccassi
2021-02-19 11:06 ` Juraj Linkeš
2021-02-19 11:33   ` Luca Boccassi
2021-02-19 12:10     ` Juraj Linkeš
2021-02-19 13:04       ` Luca Boccassi
2021-02-24 12:51         ` Juraj Linkeš [this message]
2021-02-20  3:42       ` Ruifeng Wang
2021-02-25 12:14         ` Jerin Jacob Kollanukkaran
2021-02-25 14:24           ` David Marchand
2021-03-01  5:40           ` Ruifeng Wang
2021-03-07 13:35             ` Jerin Jacob Kollanukkaran
2021-03-08  3:23               ` Ruifeng Wang
2021-03-08 12:08                 ` Luca Boccassi
2021-03-08 18:51                   ` [dpdk-stable] [dpdk-dev] " Jerin Jacob
2021-03-08 18:48                 ` Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=899bb05e35724b3e93802298c35906a1@pantheon.tech \
    --to=juraj.linkes@pantheon.tech \
    --cc=bluca@debian.org \
    --cc=david.marchand@redhat.com \
    --cc=jerinj@marvell.com \
    --cc=ruifeng.wang@arm.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).