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

[Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.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.

>>
>> Also, do you think +crypto needs to be removed from default n2
>config as its
>> optional?
>Agree. Better to move it to SoC specific configuration.
>
>>
>> >Juraj, do you remember the exact issue?
>> >
>> >>
>> >> [1]https://urldefense.proofpoint.com/v2/url?u=https-
>> >3A__developer.arm.com_tools-2Dand-2Dsoftware_open-2Dsource-
>> >2D&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-
>> >fmvgGV3o-g_fjLhk5Pupi9ijohpc&m=0oZnXDnO-
>>
>>oYL9lESEaZt_nH_kK8Nc3m0tvdEPpKeFZc&s=WxrPoWhkM2QIFGEKezP
>K
>> >D9oEn7nGFvvgS2ul9ZYx-Kg&e=
>> >> software/developer-tools/gnu-toolchain/architecture-support
>> >>
>> >>
>> >> >[1] https://urldefense.proofpoint.com/v2/url?u=https-
>> >> >3A__developer.arm.com_ip-
>> >> >2Dproducts_processors_neoverse_neoverse-
>> >>
>>
>>>2Dn2&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVs
>B
>> >-
>> >> >fmvgGV3o-
>> >>
>>
>>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
>> >W
>> >> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-
>> >3EhTVBabm3SW8&e=
>> >> >
>> >> ><snip>