Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions

From: Bruce Richardson <bruce.richardson@intel.com>
To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"juraj.linkes@pantheon.tech" <juraj.linkes@pantheon.tech>,
	Jan Viktorin <viktorin@rehivetech.com>,
	Ruifeng Wang <Ruifeng.Wang@arm.com>,
	"dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express arch extensions
Date: Wed, 12 May 2021 10:31:23 +0100	[thread overview]
Message-ID: <YJuga5+zK/3AzFgh@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <PH0PR18MB4086C57C7602AB967A28182DDE529@PH0PR18MB4086.namprd18.prod.outlook.com>

On Wed, May 12, 2021 at 09:17:31AM +0000, Pavan Nikhilesh Bhagavatula wrote:
> 
> ><snip>
> >
> >>
> >> >> >>
> >> >> >> >
> >> >> >> > 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