All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liang Ma <liangma@liangbit.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	dev@dpdk.org, Konstantin Ananyev <konstantin.ananyev@intel.com>
Subject: Re: [dpdk-dev] Question Of binutils-avx512-check
Date: Fri, 21 May 2021 09:55:37 +0100	[thread overview]
Message-ID: <YKd1iQP9BENlfqtk@C02F33EJML85> (raw)
In-Reply-To: <YKdtKZ4f5rrpKOMF@bricha3-MOBL.ger.corp.intel.com>

On Fri, May 21, 2021 at 09:19:53AM +0100, Bruce Richardson wrote:
> On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote:
> > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote:
> > > 20/05/2021 23:22, Liang Ma:
> > > > Hi All, 
> > > >    I try to build DPDK with debug  build-type but the building process is
> > > >    failed becuase of AVX512 code from librte-acl. The release build type
> > > >    is fine. Hence, I dig a bit into the avx512 enabling logic of meson.
> > > > 
> > > >    I found the main logic is implemented inside binutils-avx512-check.sh.
> > > > 
> > > >    It looks the script focus on checking the compatiblity of tools-chain
> > > >    instead of CPUID. My problem is current script will produce avx512
> > > >    code even I build dpdk on AMD platform. I understand the avx512 code
> > > >    may not be used in runtime. I just wonder why we can not check the
> > > >    cpuid as well ?
> > > 
> > > The same binary can be run on multiple CPUs,
> > > so it makes no sense to check the compilation CPUID in generic compilation.
> > > For native build, why not.
> > > 
> > > Anyway, your problem is at compilation, not runtime, right?
> > Yes, the problem is at compilation. 
> > Given X86_64, gcc-6.30, Debug build always failed due
> > to librte_acl AVX512 code. I hope there is a graceful switch allow
> > developer disable avx512 in certain circumstance.
> 
> Add ACL maintainer on CC. Sounds like there is a problem with the AVX512
> support detection for acl library. Looking at the meson build code, other
> drivers, such as i40e, do their avx512 detection differently from ACL.
there are 2 concerns here: 
1. librte_acl specific issue cause the debug building failure with gcc 6.30.
2. More generic, if that's possible to have a graceful switch for avx512.(e.g. build option) 


  reply	other threads:[~2021-05-21  8:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 21:22 [dpdk-dev] Question Of binutils-avx512-check Liang Ma
2021-05-21  7:04 ` Thomas Monjalon
2021-05-21  7:56   ` Liang Ma
2021-05-21  8:19     ` Bruce Richardson
2021-05-21  8:55       ` Liang Ma [this message]
2021-05-21  9:07         ` Bruce Richardson
2021-05-21  9:56           ` Liang Ma
2021-05-21  9:52         ` Ananyev, Konstantin
2021-05-21 10:01           ` Liang Ma

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=YKd1iQP9BENlfqtk@C02F33EJML85 \
    --to=liangma@liangbit.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=thomas@monjalon.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.