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

[Juraj Linkeš]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson at intel.com>
> Sent: Wednesday, May 12, 2021 11:31 AM
> To: Pavan Nikhilesh Bhagavatula <pbhagavatula at marvell.com>
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>;
> thomas at monjalon.net; Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Juraj
> Linkeš <juraj.linkes at pantheon.tech>; Jan Viktorin <viktorin at rehivetech.com>;
> Ruifeng Wang <Ruifeng.Wang at arm.com>; dev at dpdk.org; nd <nd at arm.com>
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] config/arm: add ability to express
> arch extensions
> 
> 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?
> 

We need a place to define SoC specific configuration that would be accessible to both native and cross builds. A separate file for each SoC would be great and I've thought about native files in the past where we'd have:
1. an SoC specific file such as soc_armada_config
2. a cross file for each compiler, such as arm64_linux_gcc

This we'd we could use the first file in native builds (and we wouldn't need the platform parameter) and we'd use both files in cross builds.

I have a hazy memory of trying something similar in 0.47.1 (splitting the cross file into SoC config and the rest), but it didn't work, both of the files needed all of the mandatory sections and I suspect this is still true judging from the docs (even for the latest Meson).

> /Bruce
> 
> [1] https://mesonbuild.com/Native-environments.html