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 BCB97A0C43; Wed, 12 May 2021 11:31:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4145D4003F; Wed, 12 May 2021 11:31:36 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 36AF84003E for ; Wed, 12 May 2021 11:31:33 +0200 (CEST) IronPort-SDR: UIvZADdjzm2yB0wWcN6fRQlSzNEZ4Yf8xfJpwF3Bo6Lhe9bHcBtE5Sd+s8GCPJj2Yoeig1+cZD 3gsRNlQ/1jBQ== X-IronPort-AV: E=McAfee;i="6200,9189,9981"; a="197683997" X-IronPort-AV: E=Sophos;i="5.82,293,1613462400"; d="scan'208";a="197683997" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2021 02:31:30 -0700 IronPort-SDR: mdvRprPwAfTTHfRZnz4ubIIycLUhZdR8Wz4wcfOEK3LT+AmIOdb7gJif9P7ggtUgrdAV/rSmCp rNECSdG7j6OQ== X-IronPort-AV: E=Sophos;i="5.82,293,1613462400"; d="scan'208";a="625240314" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.19.33]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 12 May 2021 02:31:26 -0700 Date: Wed, 12 May 2021 10:31:23 +0100 From: Bruce Richardson To: Pavan Nikhilesh Bhagavatula Cc: Honnappa Nagarahalli , "thomas@monjalon.net" , Jerin Jacob Kollanukkaran , "juraj.linkes@pantheon.tech" , Jan Viktorin , Ruifeng Wang , "dev@dpdk.org" , nd Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions 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 Wed, May 12, 2021 at 09:17:31AM +0000, Pavan Nikhilesh Bhagavatula wrote: > > > > > > >> > >> >> >> > >> >> >> > > >> >> >> > The patch still holds true for CRC though as it is listed > >> >> >> > separately below > >> >> >> > https://urldefense.proofpoint.com/v2/url?u=https- > >> >> >3A__developer.arm.com_architectures_cpu-2Darchitecture_a- > >> >> > >>2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB- > >> >> >fmvgGV3o- > >> >> > >> > >>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc > >> >W > >> >> > >> > >>>d9nAmM&s=fA4SM6O3iC2HXIK1qSbOHzxVeHoYqcfUebEOwioHC7c& > >e > >> >= > >> >> >> > profile/exploration-tools/feature-names-for-a-profile > >> >> >CRC is mandatory starting in V8.1, refer to Arm-ARM document. > >> >> > > >> >> >> > > >> >> >> > Also, looks like sve2 support in n2 core might be optional as > >> >> >> > per > >> >> >above doc? > >> >> >> I need to check on this. Some of the info here might not be > >public > >> >yet. > >> >> >I found [1]. SVE2 is mandatory feature. > >> >> > > >> >> > >> >> I see thanks for the info I will remove extension from cnxk. > >> >> > >> >> Do you think the extension infra is still useful for other cases? i.e. > >> >older cores > >> >> or cases where vendor wants to enable some extensions by > >default? > >> >> > >> >> I found a document[1] which describes about extensions not > >enabled > >> >by > >> >> default but supported by a given march. > >> >> In case of n2 I think memory tagging is one such feature > >> >I think the reference is providing a different information than what > >> >you are trying to achieve here. > >> > > >> >It looks like you are trying to address a use case where in the same > >> >CPU IP has different features enabled/disabled on different SoCs. > >> >This is a valid use case from crypto perspective (due to export > >control > >> >reasons) where-in 2 different SoCs might have crypto > >enabled/disabled. > >> >I am not sure if other features can be enabled/disabled. But, Crypto > >> >feature is a good enough reason to address such a use case. > >> > >> Yes, that's my intension apologies if the commit log doesn't clarify it > >properly. > >> > >> > > >> >IMO, we should capture the SoC specific details in SoC specific files, > >> >in this case in 'arm64_cn10k_linux_gcc'. I believe there were some > >> >challenges in doing this. > >> > >> Since, all the flags are populated through soc_* variable and > >> arm64_cn10k_linux_gcc also translates to soc_cn10k I believe the > >extensions > >> should be reported through > >> soc_* variables. > >IMO, there will be more SoCs in the future. I prefer to not grow > >meson.build. > > Problem is native build wouldn't read arm64_*_linux_gcc, it will be really > hard to parse it and read extensions if they are placed there. > Since our minimum meson version for DPDK is >0.49, would native-build files[1] for meson offer a solution here? /Bruce [1] https://mesonbuild.com/Native-environments.html