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 B2539A0547; Mon, 24 May 2021 15:15:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9CC5E40150; Mon, 24 May 2021 15:15:59 +0200 (CEST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id CC29D4003E for ; Mon, 24 May 2021 15:15:57 +0200 (CEST) Received: from dggems705-chm.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Fpd0h0Qw3zmkm2; Mon, 24 May 2021 21:12:20 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggems705-chm.china.huawei.com (10.3.19.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 24 May 2021 21:15:55 +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, 24 May 2021 21:15:54 +0800 To: Ruifeng Wang , "thomas@monjalon.net" , "ferruh.yigit@intel.com" CC: "dev@dpdk.org" , "jerinj@marvell.com" , "viktorin@rehivetech.com" , "bruce.richardson@intel.com" , "Honnappa Nagarahalli" , "jerinjacobk@gmail.com" , "juraj.linkes@pantheon.tech" , nd References: <1620808126-18876-1-git-send-email-fengchengwen@huawei.com> <1621430731-27753-1-git-send-email-fengchengwen@huawei.com> <1621430731-27753-3-git-send-email-fengchengwen@huawei.com> <54ced40e-f0dd-faf9-2a5c-2a3949812627@huawei.com> From: fengchengwen Message-ID: <8864c54a-d4df-c9f5-236c-edf15661607e@huawei.com> Date: Mon, 24 May 2021 21:15:54 +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: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH v6 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" Fix in v7, thanks On 2021/5/24 18:03, Ruifeng Wang wrote: >> -----Original Message----- >> From: fengchengwen >> Sent: Monday, May 24, 2021 4:44 PM >> To: Ruifeng Wang ; thomas@monjalon.net; >> ferruh.yigit@intel.com >> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com; >> bruce.richardson@intel.com; Honnappa Nagarahalli >> ; jerinjacobk@gmail.com; >> juraj.linkes@pantheon.tech; nd >> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method >> >> >> >> On 2021/5/24 13:38, Ruifeng Wang wrote: >>>> -----Original Message----- >>>> From: fengchengwen >>>> Sent: Friday, May 21, 2021 2:53 PM >>>> To: Ruifeng Wang ; thomas@monjalon.net; >>>> ferruh.yigit@intel.com >>>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com; >>>> bruce.richardson@intel.com; Honnappa Nagarahalli >>>> ; jerinjacobk@gmail.com; >>>> juraj.linkes@pantheon.tech; nd >>>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile >>>> method >>>> >>>> >>>> >>>> On 2021/5/21 13:21, Ruifeng Wang wrote: >>>>>> -----Original Message----- >>>>>> From: fengchengwen >>>>>> Sent: Thursday, May 20, 2021 6:55 PM >>>>>> To: Ruifeng Wang ; thomas@monjalon.net; >>>>>> ferruh.yigit@intel.com >>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com; >>>>>> bruce.richardson@intel.com; Honnappa Nagarahalli >>>>>> ; jerinjacobk@gmail.com; >>>>>> juraj.linkes@pantheon.tech; nd >>>>>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile >>>>>> method >>>>>> >>>>>> >>>>>> >>>>>> On 2021/5/20 16:24, Ruifeng Wang wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: Chengwen Feng >>>>>>>> Sent: Wednesday, May 19, 2021 9:26 PM >>>>>>>> To: thomas@monjalon.net; ferruh.yigit@intel.com >>>>>>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang >>>>>>>> ; viktorin@rehivetech.com; >>>>>>>> bruce.richardson@intel.com; Honnappa Nagarahalli >>>>>>>> ; jerinjacobk@gmail.com; >>>>>>>> juraj.linkes@pantheon.tech; nd >>>>>>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile >>>>>>>> method >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> 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 >>>>>>>> --- >>>>>>>> drivers/net/hns3/hns3_rxtx.c | 2 +- >>>>>>>> drivers/net/hns3/meson.build >>>>>>>> | >>>>>>>> 21 ++++++++++++++++++++- >>>>>>>> 2 files changed, 21 insertions(+), 2 deletions(-) >>>>>>>> >>>>>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c >>>>>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644 >>>>>>>> --- a/drivers/net/hns3/hns3_rxtx.c >>>>>>>> +++ b/drivers/net/hns3/hns3_rxtx.c >>>>>>>> @@ -2808,7 +2808,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(CC_SVE_SUPPORT) >>>>>>>> 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..5f9af9b 100644 >>>>>>>> --- a/drivers/net/hns3/meson.build >>>>>>>> +++ b/drivers/net/hns3/meson.build >>>>>>>> @@ -35,7 +35,26 @@ 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 cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != >> '' >>>>>>>> + and >>>>>>>> cc.check_header('arm_sve.h') >>>>>>>> + cflags += ['-DCC_SVE_SUPPORT'] >>>>>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined. >>>>>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one. >>>>>>> >>>>>> >>>>>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args >>>> which >>>>>> support SVE, it can't deals with the situation: the default >>>>>> machine_args don't support SVE but compiler support SVE. >>>>>> So the CC_SVE_SUPPORT marco is necessary. >>>>> Agree that macro for SVE is also needed here. And we can also use '- >>>> DCC_SVE_ACLE_SUPPORT' here right? >>>>> I think there is no difference between CC_SVE_ACLE_SUPPORT and >>>> CC_SVE_SUPPORT when they are used in source code. >>>>> IMO the same macro name can be used, and it removes redundancy and >>>> confusion. >>>>> >>>> >>>> You are right, no difference between CC_SVE_ACLE_SUPPORT and >>>> CC_SVE_SUPPORT But the hns3 sve already support 20.11, and >>>> CC_SVE_ACLE_SUPPORT was newly defined, there maybe some >> problems when >>>> backporting. >>> 20.11 release has no machine enabled SVE extension. >>> >>>> >>>> Or we could redefine CC_SVE_ACLE_SUPPORT under default >> machine_args: >>>> if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' >>>> and >>>> cc.check_header('arm_sve.h') >>>> cflags += ['-DCC_SVE_ACLE_SUPPORT'] >>> 'if dpdk_conf.get(CC_SVE_ACLE_SUPPORT)' should be fine? >>> Stable branch has no SVE enabled in machine_args. >>> >> >> But 20.11 use could use hns3 SVE path when compile with gcc10. > 20.11 user will be able to use hns3 SVE path. > Implementation 'a' should be fine for both 20.11 and 21.08. > >> >> If we reuse the CC_SVE_ACLE_SUPPORT macro, there maybe problem when >> backporting: >> a. In 21.08 we could depend on CC_SVE_ACLE_SUPPORT, so it will be: >> if dpdk_conf.get('CC_SVE_ACLE_SUPPORT') >> sources += files('hns3_rxtx_vec_sve.c') >> elif cc.has_argument('-march=armv8.2-a+sve') and >> cc.check_header('arm_sve.h') > gcc10 user will go into this branch, and SVE path will be included. > It is identical in 'a' and 'b'. > >> sve_cflags = ['-DCC_SVE_ACLE_SUPPORT'] >> ... >> b. But for backport to 20.11, we should use another impl: >> if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and >> cc.check_header('arm_sve.h') > 'if' clause in implementation 'a' will have the same behavior as this one in 20.11. > Both of the checks will be false. > 'CC_SVE_ACLE_SUPPORT' is not defined in 20.11 -> result in false. > No machine_args have sve enabled in 20.11 -> result in false. > So I think there is a chance we can use a single macro. > >> cflags += ['-DCC_SVE_ACLE_SUPPORT'] >> sources += files('hns3_rxtx_vec_sve.c') >> elif cc.has_argument('-march=armv8.2-a+sve') and >> cc.check_header('arm_sve.h') >> sve_cflags = ['-DCC_SVE_ACLE_SUPPORT'] >> ... >> As you see, the above two are not unified. >> >> So here I think use the CC_SVE_SUPPORT is appropriate. >> >> @Ferruh what's your opinion ? >> >>>> sources += files('hns3_rxtx_vec_sve.c') >>>> elif cc.has_argument('-march=armv8.2-a+sve') and >>>> cc.check_header('arm_sve.h') >>>> sve_cflags = ['-DCC_SVE_ACLE_SUPPORT'] >>> This is fine. Macro name is consistent. >>> >>>> foreach flag: cflags >>>> # filterout -march -mcpu -mtune >>>> if not (flag.startswith('-march=') or >>>> flag.startswith('-mcpu=') or >>>> flag.startswith('-mtune=')) >>>> sve_cflags += flag >>>> endif >>>> endforeach >>>> but this way may introduce coupling, I think. >>>> >>>>>> >>>>>>> [1] >>>>>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1- >> git- >>>>>>> se >>>>>>> nd >>>>>>> -email-fengchengwen@huawei.com/ >>>>>>> >>>>>>>> sources += files('hns3_rxtx_vec_sve.c') >>>>>>>> + elif cc.has_argument('-march=armv8.2-a+sve') and >>>>>>>> cc.check_header('arm_sve.h') >>>>>>>> + sve_cflags = ['-DCC_SVE_SUPPORT'] >>>>>>>> + foreach flag: cflags >>>>>>>> + # filterout -march -mcpu -mtune >>>>>>>> + 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 >>>>>>> >>>>>>> >>>>>>> . >>>>>>> >>>>> >>> >