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 6ED5BA0A02; Fri, 21 May 2021 09:04:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34C3A40143; Fri, 21 May 2021 09:04:14 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id 135DB40041 for ; Fri, 21 May 2021 09:04:12 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8D49012D8; Fri, 21 May 2021 03:04:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 21 May 2021 03:04:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= HUM308f+gbmb49jyOe0eXkkpSd7rU0yBxlDzQz6wK7A=; b=VY90x69CchC37QTT 4HNUx6MHdwvGYscoZQ+BG/yvfJV6IW3BLd8axRySiwHSTM90IxbcmfNcZDQnpM94 er0WsHlKyH2KvXFptwoGMTQnbKvaZrzaYbJJxblE68sEBBDY2WR4lVauwC4I0uzg k6HhfZgAin1y0jBZ6j2JPewIjx6VdOh6vS/zucjI3yOLMB1OxHT7eETIbDP2FJ0C 3k+Y5Jy0wiyyUQXNKe06IGZ2eteHlSa5fW5BlJMD/XrGWWNWvU9FI+S3oMjlNMW8 +i85IXqbhPF6DsgOG1iTv5UrYwhNFlIxORQltjYZTsQIBXN7+5z21gcQ2rYqm4oR LK1Ftg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=HUM308f+gbmb49jyOe0eXkkpSd7rU0yBxlDzQz6wK 7A=; b=V+fTLg02e7F+c39+1YStRGq5np2Ljq+G9xiRBOjjMOj3265hZbOjOO6SQ DFUYAL4HIxeeHWiPNDz4THX4fjFvvyrt2/+7U9Arrm4q9QP9vy6y+R0xYsqJs9+e LFm5fNjeDrj5C0sxCF+Q1tYAtWYGba2Nc2B14PKXRolY1WwR8WvynBOiL0MX/M5R kF3zVfEqUI0J5+36iCfhB920+2TdUZJcFn3643tibqWHpjHxfKp0GNsf96A5sl72 PRuArUk60A3TpQa6rVU6YSO0GxlIMIbPAXI6LPV8ud5wZPoxCYDVASOwin2oIMbY MmEZYWEWmZwXpLjT0IM3LuHg7ElXA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejvddguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 21 May 2021 03:04:09 -0400 (EDT) From: Thomas Monjalon To: Liang Ma Cc: dev@dpdk.org, bruce.richardson@intel.com Date: Fri, 21 May 2021 09:04:06 +0200 Message-ID: <28959083.qiruW6CpZX@thomas> In-Reply-To: <20210520212203.GA26@DESKTOP-POQV63C.localdomain> References: <20210520212203.GA26@DESKTOP-POQV63C.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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?