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

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<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).
Are we concluding there is no solution?

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