From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 830B3A04C7; Wed, 16 Sep 2020 11:49:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 083791C20E; Wed, 16 Sep 2020 11:49:11 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 92F861C12F for <dev@dpdk.org>; Wed, 16 Sep 2020 11:49:09 +0200 (CEST) IronPort-SDR: wF9FErJcle9T2xMUeYkkD2z0+Sw0sUaZx01B2X4O+YTorIqddgpUf/pV126aibFzrP/UUnoOoQ fdKYtmWJv0rg== X-IronPort-AV: E=McAfee;i="6000,8403,9745"; a="147186716" X-IronPort-AV: E=Sophos;i="5.76,432,1592895600"; d="scan'208";a="147186716" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2020 02:49:08 -0700 IronPort-SDR: XWoNvH6QhYDUpt13Cjs/80jZLd92R1n7p4FHHtpYGCiCtqJooGCrE7mEME9fJxCMbxkt9YLifj uQCmRu2Wf3Lg== X-IronPort-AV: E=Sophos;i="5.76,432,1592895600"; d="scan'208";a="451786062" Received: from bricha3-mobl.ger.corp.intel.com ([10.214.245.198]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Sep 2020 02:49:06 -0700 Date: Wed, 16 Sep 2020 10:49:00 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> Cc: Konstantin Ananyev <konstantin.ananyev@intel.com>, dev@dpdk.org, jerinj@marvell.com, ruifeng.wang@arm.com Message-ID: <20200916094900.GB1849@bricha3-MOBL.ger.corp.intel.com> References: <20200807162829.11690-1-konstantin.ananyev@intel.com> <20200915165025.543-1-konstantin.ananyev@intel.com> <20200915165025.543-8-konstantin.ananyev@intel.com> <20200916091128.GA1849@bricha3-MOBL.ger.corp.intel.com> <66917b48-ce20-176a-b90e-dfebdf481d15@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66917b48-ce20-176a-b90e-dfebdf481d15@intel.com> Subject: Re: [dpdk-dev] [PATCH v2 07/12] acl: add infrastructure to support AVX512 classify X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Wed, Sep 16, 2020 at 10:36:32AM +0100, Medvedkin, Vladimir wrote: > Hi Bruce, > > On 16/09/2020 10:11, Bruce Richardson wrote: > > On Tue, Sep 15, 2020 at 05:50:20PM +0100, Konstantin Ananyev wrote: > > > Add necessary changes to support new AVX512 specific ACL classify > > > algorithm: > > > - changes in meson.build to check that build tools > > > (compiler, assembler, etc.) do properly support AVX512. > > > - run-time checks to make sure target platform does support AVX512. > > > - dummy rte_acl_classify_avx512() for targets where AVX512 > > > implementation couldn't be properly supported. > > > > > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > > > --- > > > > This all looks correct, though I wonder do you really need to check all > > those AVX512 flags in each case? Since "F" is always present in any AVX512 > > implementation perhaps it can be checked, though if the other three always > > need to be checked I can understand if you want to keep it there for > > completeness. [Are all the other 3 used in your code?] > > > > As for me it is good to check all the flags supported by compiler. Some old > (but still supported by dpdk) gcc can't compile the code in some > circumstances. For example: > > gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12) <-- pretty old > but still supported, right? > > gcc -march=native -dM -E - < /dev/null | grep "AVX512" > #define __AVX512F__ 1 > #define __AVX512BW__ 1 > #define __AVX512CD__ 1 > #define __AVX512DQ__ 1 > > Does not support __AVX512VL__ > Interesting, seems like checking them all to be sure is the right approach so. My ack stands so, and ignore the comment.