> 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://gcc.gnu.org/gcc-8/changes.html
Thanks,
Yongseok
>> 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%7Cda8fb7ed03e7406ded8908d6cee6d759%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636923888189316743&sdata=x5XNd5WZ3EtiprPMiFzaskvigX8K0AoXA2w%2BKiN156c%3D&reserved=0
>>
>>>
>>> Thanks
>>> Yongseok
