[dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 crypto extension

[Yongseok Koh]

> On May 2, 2019, at 4:08 PM, Yongseok Koh <yskoh at mellanox.com> wrote:
> 
>> 
>> On May 2, 2019, at 3:13 AM, Jerin Jacob Kollanukkaran <jerinj at marvell.com> wrote:
>> 
>>> -----Original Message-----
>>> From: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>
>>> Sent: Tuesday, April 30, 2019 9:04 AM
>>> To: yskoh at mellanox.com
>>> Cc: Jerin Jacob Kollanukkaran <jerinj at marvell.com>;
>>> bruce.richardson at intel.com; Pavan Nikhilesh Bhagavatula
>>> <pbhagavatula at marvell.com>; Shahaf Shuler <shahafs at mellanox.com>;
>>> dev at dpdk.org; thomas at monjalon.net; Gavin Hu (Arm Technology China)
>>> <Gavin.Hu at arm.com>; Honnappa Nagarahalli
>>> <Honnappa.Nagarahalli at arm.com>; nd <nd at arm.com>; nd <nd at 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.Nagarahalli at 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