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

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Yongseok Koh <yskoh at mellanox.com>
> Sent: Saturday, April 13, 2019 4:55 AM
> To: bruce.richardson at intel.com; Jerin Jacob Kollanukkaran
> <jerinj at marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula at marvell.com>; shahafs at mellanox.com
> Cc: dev at dpdk.org; thomas at monjalon.net; gavin.hu at arm.com;
> Honnappa.Nagarahalli at arm.com
> 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?