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 E1B22A0A02; Fri, 21 May 2021 12:01:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6711D40143; Fri, 21 May 2021 12:01:51 +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 5696840041 for ; Fri, 21 May 2021 12:01:50 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1621591303; cv=none; d=zohomail.eu; s=zohoarc; b=XknA2c3kVWQQ41I9G/eLY2fwNiBdTDKKvgCIAjy7922p9BmubgFsN12s+yQdGD6te/ZO6gZGMsa8x14L2Mb++mhRR5oy0sRGAdDgSMg5helMsc0AQh5xr9FN0aoKsuP+Lmpoh4MB0TTcyL2C3nNDbXn2bSI4pBFWmhX+Wu7QQ6E= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1621591303; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=LZreNyfX8UJaGWCyQXIixJ29Mp9/+pI8h2pEDjr0zqA=; b=KhtaWbYUChX5hHTwceCs22jqprnz/CwWDDGlz8gqSachwpL9G3TZsKbSs9s8fcHjLNs0cIY2cwPQD+4NDg0q98bsm1+DXNjbfOuqkpe+RBs9w7pvuoQW9AGY5wjEhCsd+zoCR0O4lUVFWOgwyzP8HnBKR9Jv83gv1ayC/KOy/T8= 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 1621591301509880.2391193145552; Fri, 21 May 2021 12:01:41 +0200 (CEST) Date: Fri, 21 May 2021 11:01:39 +0100 From: Liang Ma To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , Thomas Monjalon , "dev@dpdk.org" 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 09:52:30AM +0000, Ananyev, Konstantin 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. > > If you feel something is wrong in particular, please let me know. > > > there are 2 concerns here: > > 1. librte_acl specific issue cause the debug building failure with gcc 6.30. > > gcc 6.3 is pretty rare these days, but I'll try to find one to reproduce the issue. > Meanwhile can you follow the procedure - open a new ticket in bugzilla, > and provide more info: command to reproduce, particular error output, etc. Many thanks! I will log it in bugzilla. > > > 2. More generic, if that's possible to have a graceful switch for avx512.(e.g. build option) > > I don't see much point in that. > avx512 code-path wouldn't be used at run-time if your box doesn't support it. sure, I understand the code path will not be touched at run-time. but put it this way, what's the point to include this code in binary, if I know the box not support it. It's nice to have a knob :-).