> On May 1, 2019, at 9:12 PM, Honnappa Nagarahalli > <honnappa.nagaraha...@arm.com> wrote: > >> >> Mellanox BlueField has a variant which doesn't have armv8 crypto extension. >> If crypto enabled binary runs on such a pltform, rte_eal_init() fails. To >> have >> binary compatibility across multiple variants, it is disabled by default and >> can >> be enabled for crypto enabled parts. >> >> Signed-off-by: Yongseok Koh <ys...@mellanox.com> >> --- >> config/defconfig_arm64-bluefield-linuxapp-gcc | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/config/defconfig_arm64-bluefield-linuxapp-gcc >> b/config/defconfig_arm64-bluefield-linuxapp-gcc >> index b496538819..6da9c2026d 100644 >> --- a/config/defconfig_arm64-bluefield-linuxapp-gcc >> +++ b/config/defconfig_arm64-bluefield-linuxapp-gcc >> @@ -10,6 +10,12 @@ CONFIG_RTE_ARCH_ARM_TUNE="cortex-a72" >> CONFIG_RTE_MAX_NUMA_NODES=1 >> CONFIG_RTE_CACHE_LINE_SIZE=64 >> >> +# Crypto extension of armv8 >> +# >> +# Disabled by default for binary compatibility. >> +# Can be enabled for crypto-enabled parts. >> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=n > How do you plan to support the Bluefield devices with crypto enabled? Do you > plan to add another config?
Nope, user will have to enable it by modifying this file or specifying it in make command line. This is just to provide the default which can make majority of cases work well. For example, by default, mlx4/5 are even disabled in default x86 build config because not all users have drv/lib installed on their system. Users have to enable it if they want. >> + >> # UMA architecture >> CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n >> CONFIG_RTE_LIBRTE_VHOST_NUMA=n >> -- >> 2.11.0
