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 EA663A0A0C; Mon, 28 Jun 2021 05:56:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6DC0F40692; Mon, 28 Jun 2021 05:56:16 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id CEB524068A for ; Mon, 28 Jun 2021 05:56:14 +0200 (CEST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4GCtvx66qGz72yb; Mon, 28 Jun 2021 11:51:57 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 28 Jun 2021 11:56:09 +0800 Received: from [127.0.0.1] (10.40.190.165) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 28 Jun 2021 11:56:09 +0800 To: Ruifeng Wang , "thomas@monjalon.net" , "ferruh.yigit@intel.com" CC: "dev@dpdk.org" , "bruce.richardson@intel.com" , "vladimir.medvedkin@intel.com" , "viktorin@rehivetech.com" , "jerinj@marvell.com" , Honnappa Nagarahalli , "jerinjacobk@gmail.com" , "juraj.linkes@pantheon.tech" , nd References: <1624849071-56826-1-git-send-email-fengchengwen@huawei.com> <1624849071-56826-3-git-send-email-fengchengwen@huawei.com> From: fengchengwen Message-ID: <64884cdd-ad03-dbab-7691-05812c075451@huawei.com> Date: Mon, 28 Jun 2021 11:56:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.40.190.165] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH 2/2] net/hns3: fix SVE code compile error with gcc8.3 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 2021/6/28 11:33, Ruifeng Wang wrote: >> -----Original Message----- >> From: Chengwen Feng >> Sent: Monday, June 28, 2021 10:58 AM >> To: thomas@monjalon.net; ferruh.yigit@intel.com; Ruifeng Wang >> >> Cc: dev@dpdk.org; bruce.richardson@intel.com; >> vladimir.medvedkin@intel.com; viktorin@rehivetech.com; >> jerinj@marvell.com; Honnappa Nagarahalli >> ; jerinjacobk@gmail.com; >> juraj.linkes@pantheon.tech >> Subject: [PATCH 2/2] net/hns3: fix SVE code compile error with gcc8.3 >> >> If the target machine has SVE feature (e.g. '-march=armv8.2-a+sve'), and >> compiler are gcc8.3, it will compile error, the error is arm_sve.h no such file or >> directory. >> >> The solution: >> a. If RTE_HAS_SVE_ACLE defined (it means the minimum instruction set >> support SVE ACLE) then compiles it. >> b. Else if the compiler support SVE ACLE then compiles it. >> c. Otherwise don't compile it. >> >> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx") >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx") >> Cc: stable@dpdk.org >> >> Signed-off-by: Chengwen Feng >> Acked-by: Ruifeng Wang >> --- >> drivers/net/hns3/hns3_rxtx.c | 2 +- >> drivers/net/hns3/meson.build | 20 +++++++++++++++++++- >> 2 files changed, 20 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c >> index cb9eccf..a86e105 100644 >> --- a/drivers/net/hns3/hns3_rxtx.c >> +++ b/drivers/net/hns3/hns3_rxtx.c >> @@ -2811,7 +2811,7 @@ hns3_get_default_vec_support(void) >> static bool >> hns3_get_sve_support(void) >> { >> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE) >> +#if defined(RTE_HAS_SVE_ACLE) >> if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256) >> return false; >> if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE)) >> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build >> index 53c7df7..a99e0db 100644 >> --- a/drivers/net/hns3/meson.build >> +++ b/drivers/net/hns3/meson.build >> @@ -35,7 +35,25 @@ deps += ['hash'] >> >> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64') >> sources += files('hns3_rxtx_vec.c') >> - if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' >> + >> + # compile SVE when: >> + # a. support SVE in minimum instruction set baseline >> + # b. it's not minimum instruction set, but compiler support >> + if dpdk_conf.has('RTE_HAS_SVE_ACLE') >> sources += files('hns3_rxtx_vec_sve.c') >> + elif cc.has_argument('-march=armv8.2-a+sve') and >> cc.check_header('arm_sve.h') >> + cflags += ['-DRTE_HAS_SVE_ACLE=1'] >> + sve_cflags = [] > Global cflags will be changed here. I think it is not very good as build of other parts could be without SVE support. > How about " sve_cflags = ['-DRTE_HAS_SVE_ACLE=1']" and drop changes to cflags? > In this way, the additional flag will be limited to hns3_sve_lib. This will not change global cflags: the cflags was independent from other drives [implemented in drivers/meson.build] And I also check the 'build.ninja' and found the RTE_HAS_SVE_ACLE only defined with hns3 driver source file. PS: hns3_rxtx.c also refer the marco 'RTE_HAS_SVE_ACLE'. > >> + foreach flag: cflags >> + if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or >> flag.startswith('-mtune=')) >> + sve_cflags += flag >> + endif >> + endforeach >> + hns3_sve_lib = static_library('hns3_sve_lib', >> + 'hns3_rxtx_vec_sve.c', >> + dependencies: [static_rte_ethdev], >> + include_directories: includes, >> + c_args: [sve_cflags, '-march=armv8.2-a+sve']) >> + objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c') >> endif >> endif >> -- >> 2.8.1 > > > . >