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 98E8AA0A02; Tue, 18 May 2021 15:45:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 77A494068E; Tue, 18 May 2021 15:45:31 +0200 (CEST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by mails.dpdk.org (Postfix) with ESMTP id 1330440041 for ; Tue, 18 May 2021 15:45:30 +0200 (CEST) Received: by mail-io1-f42.google.com with SMTP id a11so9462706ioo.0 for ; Tue, 18 May 2021 06:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Nd5BNF2gLJwm3JWk8ClFHDyxe9mqaiGKcVs7ZugJiOI=; b=pMR3DHfkBa47c72cJumuYY5SVmZxLKsvHA4+txM2bfA3rZ0rydlLnohJowv2lgzHGB n9wO5oQCd+vKbCw5J1RiYyE4AutiDj7I6iTWJLe405loqQ5C003ilAo1OHFYlMIJUEfY 8jRfCzxEMhQo/t/8MxLZWYLvwjXNR3ys7/2oZ2Yo9WYnIxiBRuUAbl7nc+PnXPw2NdWr ZfIqFuc2M4b4vterNdW6z7kiZdFx1Lxt8Q0bG0PKFowT516uFIUV6EfSCymvx6pTtFhi bJznJy6auktaVzBoPyvnQz62DaQDQx8kJ4UNpeWxBAoA3hK9lP8i5rSP6ea8Z41jun1O foLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Nd5BNF2gLJwm3JWk8ClFHDyxe9mqaiGKcVs7ZugJiOI=; b=Tj441wtasf94wjtnXqLHTB+ilu1M+lRMhVoFyyL8M+HFTxU2MWRGgkTLeTrJFdTCrb dgg00NnowW3XUjScM2TIrMMR2mPioSim44c1j6QfU434QhYT9yOT/xUS7fF+Elz3EgE7 i900ZCCrhS2Ou4ZGfT9XRTL4zLJhit/FbyAm7wxW/Kwi1s+nh10626vDVR57+ZaQeIIB 21KNYlmHOBsCL+Es75vMIEcpvDmRO87FwwHWKF1+8atkshFUdE1gbMqyFpuYFcZW24hO O2qYt9rYRg26sVJtjo+WCcX2eNwn5h8Hicmzc3el6q8bXDZT0yXXlZye8wOUVusPvoCl xd2A== X-Gm-Message-State: AOAM532QMhw+P7bHKeuOmjbhH3b32YD2XjMfILpU3s2qo3QLbvgsuQ+8 s64da5uzOVUf5zWDWL+8d7+6UfOOSpyJg0yAF8U= X-Google-Smtp-Source: ABdhPJyzueJRvn9mx8cGEwn5Xlc9l70ZYR6XUEeZqJavGjabnqF2AwpDDnqoPYqsrgdJpoK+PwAM74rfuM2U9tkZytc= X-Received: by 2002:a05:6638:2643:: with SMTP id n3mr5590990jat.104.1621345529378; Tue, 18 May 2021 06:45:29 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Jerin Jacob Date: Tue, 18 May 2021 19:15:13 +0530 Message-ID: To: Honnappa Nagarahalli Cc: fengchengwen , "thomas@monjalon.net" , Ferruh Yigit , dpdk-dev , "jerinj@marvell.com" , Ruifeng Wang , Jan Viktorin , "Richardson, Bruce" , =?UTF-8?Q?Juraj_Linke=C5=A1?= , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, May 18, 2021 at 6:55 PM Honnappa Nagarahalli wrote: > > > > > >> > > >> On Thu, May 13, 2021 at 6:41 PM Chengwen Feng > > >> wrote: > > >>> > > >>> Currently, the soc_kunpeng930 declares > > >>> '-march=3Darmv8.2-a+crypto+sve', but some compiler doesn't recogniz= e > > >>> 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=3Darmv8-a', '-march=3Darmv8.2-a'] 2. D= efine > > >>> 'march_feature' tuple which defines support feature. > > >>> e.g. 'march_feature' : ['crypto', 'sve'] 3. Select the most suitabl= e > > >>> 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 =3D { > > >>> ], > > >>> 'part_number_config': { > > >>> '0xd01': { > > >>> - 'machine_args': ['-march=3Darmv8.2-a+crypto', '-mtune= =3Dtsv110'], > > >>> + 'march_base' : ['-march=3Darmv8-a', '-march=3Darmv8.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 a= s > > >> 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 fea= tures > > 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 secti= on 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 sup= ported > > in the compiler. > > > > > > > I try to add 'march_base' : ['-march=3Darmv8-a', '-march=3Darmv8.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=3Darmv8-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 g= ap, > > 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 w= hich showed > > above. > > > > So how about add new tuple: fallback_generic? eg: > > '0xd02': { > > 'march_base': ['-march=3Darmv8.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. > Jerin, how big of a problem is this (i.e. having to compile the code with= an older version of the compiler)? Is it just one old version of the compi= ler or there are several of them? Do they all need to be captured in the me= son.build file? I am just trying to understand the need for a generic appro= ach. IMO, We are supporting from gcc 4.7. So a lot of combinations are possible. > > > > > > > >> > > >> > > >>> + 'march_feature' : ['crypto'], > > >>> + 'machine_args': ['-mtune=3Dtsv110'], > > >>> 'flags': [ > > >>> ['RTE_MACHINE', '"Kunpeng 920"'], > > >>> ['RTE_ARM_FEATURE_ATOMICS', true], @@ -158,7 +160,= 9 > > >>> @@ implementer_hisilicon =3D { > > >>> ] > > >>> }, > > >>> '0xd02': { > > >>> - 'machine_args': ['-march=3Darmv8.2-a+crypto+sve'], > > >>> + 'march_base' : ['-march=3Darmv8-a', '-march=3Darmv8.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 =3D flags_common + implementer_config['flags'] + > > >>> part_number_config.get('flags', []) + soc_flags > > >>> > > >>> + # select the most suitable march+feature combination > > >>> + machine_march =3D [] > > >>> + if part_number_config.has_key('march_base') > > >>> + foreach arch: part_number_config['march_base'] > > >>> + if cc.has_argument(arch) > > >>> + machine_march =3D 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 =3D machine_march + '+' + feature > > >>> + if cc.has_argument(tmp_machine_march) > > >>> + machine_march =3D tmp_machine_march # Set the more > > >>> + supported > > >> feature as possible > > >>> + endif > > >>> + endforeach > > >>> + endif > > >>> + > > >>> # apply supported machine args > > >>> machine_args =3D [] # Clear previous machine args > > >>> + machine_args +=3D machine_march > > >>> foreach flag: part_number_config['machine_args'] > > >>> if cc.has_argument(flag) > > >>> machine_args +=3D flag > > >>> -- > > >>> 2.8.1 > > >>> >