> > > > 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? > +1
> > > > >