05/10/2019 17:28, Jerin Jacob:
> On Fri, Oct 4, 2019 at 4:27 AM Dharmik Thakkar <dharmik.thak...@arm.com>
> wrote:
> >
> > Add new meson.build file for crypto/armv8
> >
> > Signed-off-by: Dharmik Thakkar <dharmik.thak...@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?
