From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6D0CA0A02; Fri, 21 May 2021 11:56:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 63F8540143; Fri, 21 May 2021 11:56:23 +0200 (CEST) Received: from sender11-of-o51.zoho.eu (sender11-of-o51.zoho.eu [31.186.226.237]) by mails.dpdk.org (Postfix) with ESMTP id EFD0240041 for ; Fri, 21 May 2021 11:56:21 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1621590976; cv=none; d=zohomail.eu; s=zohoarc; b=irLDz9+0J1jg4+Fb2zRbyEprgFuWitzqFpcImnTTPC5PrBguHTXex69J/qD/4fK0EWBOwIcADEiExESc1YGwQiSKeWFPUYm6Mo0AmGRBpfz/pZmvvRJtuyRAOpZps9kh4jFHI05VHphy+SW+sP/JgKJ4mDut6QnJ2Qev6+26TFU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1621590976; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=uzW4bKyRssTgrAX5xBV2wL+wcKvQoXsiRtmP96P/uTg=; b=YDejwTxyEB/dhmmOu/gbR7ravChd+q6NMNN+GXH0tlnlRbxl5DEscYIUbdIPL53X6kH7iaVVW9pgTB5CUdxyJAzKuIXjwQN8JQ+9a+fZ3EMSOoccBN//hlCceCmtUj40raO+z01TC7bXac45gNjBBdBOEN/ohxrZI5AARmefvZs= ARC-Authentication-Results: i=1; mx.zohomail.eu; spf=pass smtp.mailfrom=liangma@liangbit.com; dmarc=pass header.from= header.from= Received: from C02F33EJML85 (47.254.128.112 [47.254.128.112]) by mx.zoho.eu with SMTPS id 1621590973992263.0572612994346; Fri, 21 May 2021 11:56:13 +0200 (CEST) Date: Fri, 21 May 2021 10:56:11 +0100 From: Liang Ma To: Bruce Richardson Cc: Thomas Monjalon , dev@dpdk.org, Konstantin Ananyev Message-ID: References: <20210520212203.GA26@DESKTOP-POQV63C.localdomain> <28959083.qiruW6CpZX@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ZohoMailClient: External Subject: Re: [dpdk-dev] Question Of binutils-avx512-check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, May 21, 2021 at 10:07:07AM +0100, Bruce Richardson wrote: > On Fri, May 21, 2021 at 09:55:37AM +0100, Liang Ma wrote: > > 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. > +1. This needs to be investigated and fixed if it's causing problems. > > > 2. More generic, if that's possible to have a graceful switch for avx512.(e.g. build option) > Not sure why this is wanted because any AVX512 paths won't be used at > runtime unless suitable for use. In any case, this should be already doable > by passing -mno-avx512 flag in CFLAGS/c_args at config time. sure, that works, I use that method this moment. It's nice to have a explicit way, because I use 30 mins to figure out that way. ;-)