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

[Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>]

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

Also, do you think +crypto needs to be removed from default n2 config as its optional?

>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=WxrPoWhkM2QIFGEKezPK
>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=E3SgYMjtKCMVsB
>-
>> >fmvgGV3o-
>>
>>g_fjLhk5Pupi9ijohpc&m=i3kC8htMiHjXMoJWUn6QlDVZQCblbFrIJyMc
>W
>> >d9nAmM&s=kP_X-Co0cl4pZ64BZqy5rAFUlkMZE-
>3EhTVBabm3SW8&e=
>> >
>> ><snip>