On Thu, 10 Oct, 2019, 10:17 AM Honnappa Nagarahalli, <
honnappa.nagaraha...@arm.com> wrote:
> <snip>
>
>
>
> On Mon, 7 Oct, 2019, 3:49 PM Jerin Jacob, <jerinjac...@gmail.com> wrote:
>
>
>
> On Sun, 6 Oct, 2019, 11:36 PM Thomas Monjalon, <tho...@monjalon.net>
> wrote:
>
> 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.
>
>
>
> Note sure how I can fix it and why I need to fix it. I just dont want to
> start a parallel collaborating infrastructure for DPDK armv8.
>
>
>
>
>
> > - 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.
>
>
>
> It is different because only one company contributing to it. In this case,
> multiple companies needs to contribute.
>
>
>
> The library badly maintained in upstream as there is no incentives to
> upstream to external library. I believe each vendor has it own copy of
> that. At least Some teams in Marvell internally has copy of it.
>
> What is their incentive to upstream? They ask me the same thing.
>
>
>
>
>
> > - 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.
>
>
>
> It is SHIM layer. I would say external library also bad if it is specific
> to DPDK.
>
>
>
> I think this library should not be specific to DPDK,
>
>
>
> Sadly it is VERY specific to DPDK for doing authentication and encryption
> in one shot to improve the performance. Openssl has already has armv8
> instructions support for doing it as two pass just that performance is not
> good. For use cae such as IPsec it make sense do authentication and
> encryption in one shot for performance improvement.
>
> *[Honnappa] *I think there is a need for such a library not just for
> DPDK. It would be good if it could do UDP checksum validation for the inner
> packet as well.
>
>
>
> so it would make sense as an external library
>
>
>
> If it an external library, it does NOT make much sense for Marvell to
> maintain it(No incentive and it is pain due lack of collaboration)
>
>
>
> Either someone need to step up and maintain it if we NOT choose to make it
> as external else we can remove the PMD from dpdk(Makes life easy for
> everyone). I don't want to maintain something not upsteamble nor
> collaboration friendly aka less quality.
>
>
>
> .
>
>
>
>
> > Thoughts from ARM, other ARMv8 vendors or community?
>
>
>
> I have expressed my concerns. If there is no constructive feedback to fix
> the concern. I will plan for submitting a patch to remove the shim crypto
> Armv8 PMD from dpdk by next week.
>
> *[Honnappa] *I do not think there is a need to remove the PMD. As you
> have mentioned, many might have developed their own libraries and may be
> dependent on DPDK Armv8 PMD.
>
Problem with that approach is that, No convergence/collaboration on this
PMD aka no improvement and less quality.
>From Arm side, there have been efforts to fix the situation. Some have not
> gone far and some have shown promise, but fell flat. I can say that this is
> still a priority but I am not sure when we will have something.
>
If ARM is ready to take over the maintenance on PMD and external library
then I am fine with any decision.
Let us know. Personally, I don't like to maintain something not upsteamble
friendly.
My suggestion, we should go ahead with adding the meson build for this PMD.
>
