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 4E30EA0A02; Tue, 18 May 2021 17:15:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14E644068E; Tue, 18 May 2021 17:15:46 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 4E5D040041 for ; Tue, 18 May 2021 17:15:44 +0200 (CEST) IronPort-SDR: xXg/6IltBHfbTRfB83wII+0mKIOXLSOqCbo3TJmX2pcVs2gEM9O9RwqTHIr3KazmvVTThGPgCI rrjlPRYnkbqg== X-IronPort-AV: E=McAfee;i="6200,9189,9988"; a="200432566" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="200432566" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 08:15:41 -0700 IronPort-SDR: xoxleVGV23TRURNxcbG5QcmmL3HNCRRVfQ1Wr3FIVaGtz3rptz8zpVzlXUVu0oxf4A9yQI49Ty rbWNAJ+6SwCw== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="542009188" Received: from sjacobs1-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.22.6]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 18 May 2021 08:15:39 -0700 Date: Tue, 18 May 2021 16:15:36 +0100 From: Bruce Richardson To: Ferruh Yigit Cc: Chengwen Feng , thomas@monjalon.net, dev@dpdk.org, jerinj@marvell.com, ruifeng.wang@arm.com, viktorin@rehivetech.com, Honnappa.Nagarahalli@arm.com, jerinjacobk@gmail.com, juraj.linkes@pantheon.tech, nd@arm.com Message-ID: References: <1620808126-18876-1-git-send-email-fengchengwen@huawei.com> <1620986039-29475-1-git-send-email-fengchengwen@huawei.com> <1620986039-29475-3-git-send-email-fengchengwen@huawei.com> <3028dea0-97f6-ed06-8017-418fd55e72a3@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3028dea0-97f6-ed06-8017-418fd55e72a3@intel.com> Subject: Re: [dpdk-dev] [PATCH v5 2/2] net/hns3: refactor SVE code compile method 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 Tue, May 18, 2021 at 03:40:18PM +0100, Ferruh Yigit wrote: > On 5/14/2021 10:53 AM, Chengwen Feng wrote: > > Currently, the SVE code is compiled only when -march supports SVE > > (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this > > approach. > > > > The solution: > > a. If the minimum instruction set support SVE then compiles it. > > b. Else if the compiler support SVE then compiles it. > > c. Otherwise don't compile it. > > > > [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html > > > > Hi Chengwen, > > As far as I understand from above problem statement, you want to produce a > binary that can run in two different platforms, one supports only NEON > instructions, other supports NEON + SVE. > > For this driver should be compiled in a way to support min instruction set, > which is NEON. > > There are two build items, > > 1) hns3_rxtx_vec_sve.c > 2) rest of the library > > There is already runtime checks to select Rx/Tx functions, so it is safe to > build (1) as long as compiler supports. If the platform doesn't support SVE, the > SVE path won't be selected during runtime. > > For (2), it should be build to support NEON only, if it is compiled to support > SVE, it won't run on the platform that only supports NEON. > > So, in below, if '__ARM_FEATURE_SVE' is supported, all driver is build with SVE > support, won't this cause a problem on the NEON platform? > In that case, the rest of DPDK is being build with SVE so having one driver neon-only doesn't really make sense. Overall, the patch looks to mirror what we do for AVX2/AVX512 support in the Intel drivers, so looks ok to me. /Bruce