> On May 2, 2019, at 4:08 PM, Yongseok Koh <ys...@mellanox.com> wrote:
>
>>
>> On May 2, 2019, at 3:13 AM, Jerin Jacob Kollanukkaran <jer...@marvell.com>
>> wrote:
>>
>>> -----Original Message-----
>>> From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>
>>> Sent: Tuesday, April 30, 2019 9:04 AM
>>> To: ys...@mellanox.com
>>> Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>;
>>> bruce.richard...@intel.com; Pavan Nikhilesh Bhagavatula
>>> <pbhagavat...@marvell.com>; Shahaf Shuler <shah...@mellanox.com>;
>>> dev@dpdk.org; tho...@monjalon.net; Gavin Hu (Arm Technology China)
>>> <gavin...@arm.com>; Honnappa Nagarahalli
>>> <honnappa.nagaraha...@arm.com>; nd <n...@arm.com>; nd <n...@arm.com>
>>> Subject: RE: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension
>>>
>>>> On Apr 15, 2019, at 1:13 PM, Honnappa Nagarahalli
>>>> <honnappa.nagaraha...@arm.com> wrote:
>>>>
>>>>>>>> Subject: [EXT] [PATCH 5/6] build: add option for armv8 crypto
>>>>>>>> extension
>>>>>>>>
>>>>>>>> CONFIG_RTE_MACHINE="armv8a"
>>>>>>>> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=y
>>>>>>>
>>>>>>> This approach is not scalable. Even, it is not good for BlueField
>>>>>>> as you you need to maintain two images.
>>>>>>>
>>>>>>> Unlike other CPU flags, arm64's crypto cpu flag is really _optional_.
>>>>>>> Access to crypto instructions is always at under runtime check.
>>>>>>> See the following in rte_armv8_pmd.c
>>>>>>>
>>>>>>>
>>>>>>> /* Check CPU for support for AES instruction set */
>>>>>>> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AES)) {
>>>>>>> ARMV8_CRYPTO_LOG_ERR(
>>>>>>> "AES instructions not supported by CPU");
>>>>>>> return -EFAULT;
>>>>>>> }
>>>>>>>
>>>>>>> /* Check CPU for support for SHA instruction set */
>>>>>>> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA1) ||
>>>>>>> !rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA2)) {
>>>>>>> ARMV8_CRYPTO_LOG_ERR(
>>>>>>> "SHA1/SHA2 instructions not supported by CPU");
>>>>>>> return -EFAULT;
>>>>>>> }
>>>>>>>
>>>>>>> So In order to avoid one more config flags specific to armv8 in
>>>>>>> meson and makefile build infra And avoid the need for 6/6 patch.
>>>>>>> IMO, # Introduce optional CPU flag scheme in eal. Treat armv8
>>>>>>> crypto as optional flag # Skip the eal init check for optional flag.
>>>>>>>
>>>>>>> Do you see any issues with that approach?
>>>>>>
>>>>>> I also thought about that approach and that was my number 1 priority.
>>>>>> But, I had one question came to my mind. Maybe, arm people can
>>>>>> confirm it. Is it 100% guaranteed that compiler never makes use of
>>>>>> any of crypto instructions even if there's no specific
>>>>>> asm/intrinsic code? The crypto extension has aes, pmull,
>>>>>> sha1 and sha2. In case of rte_memcpy() for x86, for example,
>>>>>> compiler may optimize code using avx512f instructions even though
>>>>>> it is written specifically with avx2 intrinsics (__mm256_*) unless
>>>>>> avx512f is
>>>> disabled.
>>>>>>
>>>>>> If a complier expert in arm (or anyone else) confirm it is
>>>>>> completely **optional**, then I'd love to take that approach for sure.
>>>>>>
>>>>>> Copied dpdk-on-arm ML.
>>>>>>
>>>>> I do not know the answer, will have to check with the compiler team.
>>>>> I will get
>>>> back on this.
>>>>
>>>> Any update yet?
>>> Currently, enabling 'crypto' flag will generate the crypto instructions
>>> only when
>>> crypto intrinsics are used. However, when 'sha3' (part of 8.2 crypto) flag
>>> is
>>
>> The default image is 8.1 spec and except octeontx2 every other SoC is 8.1 and
>> For octeotx2 crypto is supported. If so, Should we worry this case?
>
> Right, it sounds to me that we can disable the option without having the new
> config flag until such instructions get needed. According to gcc-8 release
> note
> [1], currently '+crypto' implies '+aes' and '+sha2' while '+sha3' and '+sm4'
> are
> newly introduced. Given that armv8 crypto PMD uses external binary of
> Marvell. I
> don't see any reason to enable '+crypto'. How about simply disable it from
> armv8
> build configs?
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 7fa6ed3105..abc8cf346c 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -74,7 +74,7 @@ flags_octeontx2_extra = [
> ['RTE_USE_C11_MEM_MODEL', true]]
>
> machine_args_generic = [
> - ['default', ['-march=armv8-a+crc+crypto']],
> + ['default', ['-march=armv8-a+crc']],
> ['native', ['-march=native']],
> ['0xd03', ['-mcpu=cortex-a53']],
> ['0xd04', ['-mcpu=cortex-a35']],
> diff --git a/mk/machine/armv8a/rte.vars.mk b/mk/machine/armv8a/rte.vars.mk
> index 8252efbb7b..5e3ffc3adf 100644
> --- a/mk/machine/armv8a/rte.vars.mk
> +++ b/mk/machine/armv8a/rte.vars.mk
> @@ -28,4 +28,4 @@
> # CPU_LDFLAGS =
> # CPU_ASFLAGS =
>
> -MACHINE_CFLAGS += -march=armv8-a+crc+crypto
> +MACHINE_CFLAGS += -march=armv8-a+crc
>
>
> [1]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fgcc-8%2Fchanges.html&data=02%7C01%7Cyskoh%40mellanox.com%7C8a0d60c82a11498bf65608d6cf5327c3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636924353391308162&sdata=cuueiNi%2FdBfEJDKa8IFstwctBIrOkfZn0J7xojxgfvI%3D&reserved=0
Just to make sure, I've run examples/ipsec-secgw on BlueField and it ran well
as expected.
>>> enabled, compiler can generate 3-way exclusive OR instructions beyond the
>>> intrinsics.
>>
>> The very same problem will be applicable for Linux kernel too for
>> distribution binary case.
>> If the above statement is true about 8.2 crypto and crypto generation without
>> Intrinsics then we need to see how linux kernel handling that and align our
>> solution
>> based on that.
>>
>>> Compiler team cannot provide a guarantee that other crypto
>>> instructions will not be used beyond the intrinsics.
>>>
>>> The current suggestion is to use GNU indirect function [1] or similar. I am
>>> not
>>
>> Not sure how it helps? If we know the compiler is generating a specific
>> function
>> With crypto instruction then we can generate _alternative_ function for the
>> same
>> With hwcap?.How do we know which function compiler using compiler
>> instructions?
>>
>>
>>> sure on GNU indirect function portability.
>>
>> We are using HWCAP scheme, So we may not need the very exact GNU indirect
>> scheme to fix the issue.
>>
>>>
>>> [1]
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwillnewton.name%2F2013%2F07%2F02%2Fusing-gnu-indirect-functions%2F&data=02%7C01%7Cyskoh%40mellanox.com%7C8a0d60c82a11498bf65608d6cf5327c3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636924353391308162&sdata=WcRHom7k1MFmHzK1LYJEaI5ruMzCvvMxlFo7Ivl%2BOh4%3D&reserved=0
>>>
>>>>
>>>> Thanks
>>>> Yongseok
