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

[Thomas Monjalon <thomas@monjalon.net>]

05/10/2019 17:28, Jerin Jacob:
> 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')

You should not need such option if you provide a pkg-config file
in your library.


> 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.

This is a real issue and you are able to fix it.


> - 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

I don't see how it is different, except it is badly maintained.


> - 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)

External PMD is bad.
I think this library should not be specific to DPDK,
so it would make sense as an external library.


> Thoughts from ARM, other ARMv8 vendors or community?