<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 >
