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 E7FA7A0524; Fri, 14 May 2021 12:23:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 527C640042; Fri, 14 May 2021 12:23:33 +0200 (CEST) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id A18DD40041 for ; Fri, 14 May 2021 12:23:31 +0200 (CEST) Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FhPfW6wNXzQnPT; Fri, 14 May 2021 18:20:03 +0800 (CST) Received: from [127.0.0.1] (10.40.190.165) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.498.0; Fri, 14 May 2021 18:23:27 +0800 To: Honnappa Nagarahalli , Jerin Jacob CC: "thomas@monjalon.net" , Ferruh Yigit , dpdk-dev , "jerinj@marvell.com" , Ruifeng Wang , Jan Viktorin , "Richardson, Bruce" , =?UTF-8?Q?Juraj_Linke=c5=a1?= , nd References: <1620808126-18876-1-git-send-email-fengchengwen@huawei.com> <1620911283-55627-1-git-send-email-fengchengwen@huawei.com> <1620911283-55627-2-git-send-email-fengchengwen@huawei.com> From: fengchengwen Message-ID: Date: Fri, 14 May 2021 18:23:27 +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-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH v4 1/2] config/arm: select most suitable -march for kunpeng soc 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/5/14 7:12, Honnappa Nagarahalli wrote: > >> >> On Thu, May 13, 2021 at 6:41 PM Chengwen Feng >> wrote: >>> >>> Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve', >>> but some compiler doesn't recognize the march because it doesn't >>> support sve. >>> >>> To solve this bug we use the following scheme: >>> 1. Define 'march_base' tuple which defines support march, it should >>> arrange from lower to higher. >>> e.g. 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'] 2. Define >>> 'march_feature' tuple which defines support feature. >>> e.g. 'march_feature' : ['crypto', 'sve'] 3. Select the most suitable >>> march+feature combination based on 'march_base' and 'march_feature' >>> tuples. >>> 4. Use the selected march+feature combination as the default >>> machine_args. >>> >>> Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng") >>> >>> Signed-off-by: Chengwen Feng >>> --- >>> config/arm/meson.build | 27 +++++++++++++++++++++++++-- >>> 1 file changed, 25 insertions(+), 2 deletions(-) >>> >>> diff --git a/config/arm/meson.build b/config/arm/meson.build index >>> 3f34ec9..8551a80 100644 >>> --- a/config/arm/meson.build >>> +++ b/config/arm/meson.build >>> @@ -149,7 +149,9 @@ implementer_hisilicon = { >>> ], >>> 'part_number_config': { >>> '0xd01': { >>> - 'machine_args': ['-march=armv8.2-a+crypto', '-mtune=tsv110'], >>> + 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'], > If the compiler supports armv8.1-a, you need to choose armv8.1-a. > >> >> Another target has the same issue. Could you fix that all together as it is >> generic problem in the existing infrastructure. > I think this needs to be more generic solution. IMO, the requirement is as follows: > > 1) We need to pick the most closest march_base supported by the compiler. For ex: If the SoC support v8.2 and the compiler supports v8.1, we need to pick v8.1 > 2) SoCs are allowed to support a base march version + hand picked features from the next 1 base marchs. i.e. armv8.x compliant implementation can include any features from armv8.(x + 1). Please refer to Arm-ARM section A2 for more details. So, it is possible that the compiler supports a base march and a bunch of optional features from the next version. We need to test all the features allowed by the architecture and pick the ones that are supported in the compiler. > I try to add 'march_base' : ['-march=armv8-a', '-march=armv8.5-a'] to cn10k, and then find it can't work with ['RTE_ARM_FEATURE_ATOMICS', true] when using gcc7.2: [268/2250] Compiling C object lib/librte_stack.a.p/stack_rte_stack_lf.c.o FAILED: lib/librte_stack.a.p/stack_rte_stack_lf.c.o ... {standard input}: Assembler messages: {standard input}:13: Error: selected processor does not support `caspl x0,x1,x2,x3,[x5]' [347/2250] Compiling C object lib/librte_hash.a.p/hash_rte_cuckoo_hash.c.o ninja: build stopped: subcommand failed. make: *** [cn10k] Error 1 It seem can't simplely add '-march=armv8-a' in 'march_base'. And it require a lot of testing to get the right 'march_base' and 'march_feature' parameters. So for v5, I just modify the kunpeng930's config which was well tested. I think the 'march_base' and 'march_feature' could well solve the gcc's minor-version problem. Note: the minor-version means a few version which are closes, not big gap, like gcc5.4 and gcc10.2 For that old gcc which could not support the 'march' that defined in 'machine_args' or 'march_base' I think it better use the 'generic' profile else it will compile fail which showed above. So how about add new tuple: fallback_generic? eg: '0xd02': { 'march_base': ['-march=armv8.2-a'], 'march_feature': ['crypto', 'sve'], 'machine_args': [], 'flags': [ ['RTE_MACHINE', '"Kunpeng 930"'], ['RTE_ARM_FEATURE_ATOMICS', true], ['RTE_MAX_LCORE', 1280], ['RTE_MAX_NUMA_NODES', 16] ], 'fallback_generic': true } PS: The premise is that the 'generic' profile is tested. >> >> >>> + 'march_feature' : ['crypto'], >>> + 'machine_args': ['-mtune=tsv110'], >>> 'flags': [ >>> ['RTE_MACHINE', '"Kunpeng 920"'], >>> ['RTE_ARM_FEATURE_ATOMICS', true], @@ -158,7 +160,9 >>> @@ implementer_hisilicon = { >>> ] >>> }, >>> '0xd02': { >>> - 'machine_args': ['-march=armv8.2-a+crypto+sve'], >>> + 'march_base' : ['-march=armv8-a', '-march=armv8.2-a'], >>> + 'march_feature' : ['crypto', 'sve'], >>> + 'machine_args': [], >>> 'flags': [ >>> ['RTE_MACHINE', '"Kunpeng 930"'], >>> ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8 +453,27 >>> @@ else >>> # add/overwrite flags in the proper order >>> dpdk_flags = flags_common + implementer_config['flags'] + >>> part_number_config.get('flags', []) + soc_flags >>> >>> + # select the most suitable march+feature combination >>> + machine_march = [] >>> + if part_number_config.has_key('march_base') >>> + foreach arch: part_number_config['march_base'] >>> + if cc.has_argument(arch) >>> + machine_march = arch # Set the higher supported arch as >> possible >>> + endif >>> + endforeach >>> + endif >>> + if part_number_config.has_key('march_feature') >>> + foreach feature: part_number_config['march_feature'] >>> + tmp_machine_march = machine_march + '+' + feature >>> + if cc.has_argument(tmp_machine_march) >>> + machine_march = tmp_machine_march # Set the more supported >> feature as possible >>> + endif >>> + endforeach >>> + endif >>> + >>> # apply supported machine args >>> machine_args = [] # Clear previous machine args >>> + machine_args += machine_march >>> foreach flag: part_number_config['machine_args'] >>> if cc.has_argument(flag) >>> machine_args += flag >>> -- >>> 2.8.1 >>>