> -----Original Message-----
> From: Yongseok Koh <[email protected]>
> Sent: Saturday, April 13, 2019 4:55 AM
> To: [email protected]; Jerin Jacob Kollanukkaran
> <[email protected]>; Pavan Nikhilesh Bhagavatula
> <[email protected]>; [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]
> 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?
