Re: [dpdk-dev] [PATCH] crypto/armv8: enable meson build

[Jerin Jacob <jerinjacobk@gmail.com>]

On Fri, Oct 4, 2019 at 4:27 AM Dharmik Thakkar <dharmik.thakkar@arm.com> wrote:
>
> Add new meson.build file for crypto/armv8
>
> Signed-off-by: Dharmik Thakkar <dharmik.thakkar@arm.com>
> ---
>  drivers/crypto/armv8/meson.build | 25 +++++++++++++++++++++++++
>  drivers/crypto/meson.build       |  6 +++---
>  meson_options.txt                |  2 ++
>  3 files changed, 30 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/crypto/armv8/meson.build

>
>  option('allow_invalid_socket_id', type: 'boolean', value: false,
>         description: 'allow out-of-range NUMA socket id\'s for platforms that don\'t report the value correctly')
> +option('armv8_crypto_dir', type: 'string', value: '',
> +       description: 'path to the armv8_crypto library installation directory')

It is not specific to this patch but it is connected to this patch.

Three years back when Cavium contributed to this driver the situation
was different where only Cavium was contributing to DPDK and now we
have multiple vendors from
ARMv8 platform and ARM itself is contributing it.

When it is submitted, I was not in favor of the external library. But
various reasons it happened to be the external library where 90% meat
in this library and shim PMD
the driver moved to DPDK.

Now, I look back, It does not make sense to the external library. Reasons are
- It won't allow another ARMv8 player to contribute to this library as
Marvell owns this repo and there is no upstreaming path to this
library.
- That made this library to not have 'any' change for the last three
year and everyone have there owned copy of this driver. In fact the
library was not compiling for last 2.5 years.
- AES-NI case it makes sense to have an external library as it is a
single vendor and it is not specific to DPDK. But in this, It is
another way around
- If it an external library, we might as well add the PMD code as well
there and that only 10% of the real stuff.
We are not able able to improve anything in this library due to this situation.

Does anyone care about this PMD? If not, we might as well remove this
DPDK and every vendor can manage the external library and external
PMD(Situation won't change much)

Thoughts from ARM, other ARMv8 vendors or community?