From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 31439A04C7; Wed, 16 Sep 2020 11:36:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8A7A41C1E3; Wed, 16 Sep 2020 11:36:40 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A09E51C12F for ; Wed, 16 Sep 2020 11:36:38 +0200 (CEST) IronPort-SDR: gDllef6jAwqF4EJt1U2F6Yoz3evwfY0/Gor36R8xqcVzxfnznQ591cLdB9l5RmJdsASGosQPX+ MCqnOBsiOHzA== X-IronPort-AV: E=McAfee;i="6000,8403,9745"; a="244268102" X-IronPort-AV: E=Sophos;i="5.76,432,1592895600"; d="scan'208";a="244268102" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2020 02:36:37 -0700 IronPort-SDR: K8jwClVw3viDTFblp85XzgZoO3EXypsQKIbSzdIUG1ROevqPCMu0c7pRetoG3anKwtUYDSllEQ RFVl0hFkNDlw== X-IronPort-AV: E=Sophos;i="5.76,432,1592895600"; d="scan'208";a="451783697" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.214.233.153]) ([10.214.233.153]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2020 02:36:35 -0700 To: Bruce Richardson , Konstantin Ananyev Cc: dev@dpdk.org, jerinj@marvell.com, ruifeng.wang@arm.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> From: "Medvedkin, Vladimir" Message-ID: <66917b48-ce20-176a-b90e-dfebdf481d15@intel.com> Date: Wed, 16 Sep 2020 10:36:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200916091128.GA1849@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 >> --- > > 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__ from acl_run_avx512x8.h in first_trans8 there is _mm256_mmask_i32gather_epi32 which requires this flag, so compilation will fail. > Acked-by: Bruce Richardson > -- Regards, Vladimir