[dpdk-dev] [PATCH] maintainers: update for armv8 crypto library

[Jerin Jacob]

On Wed, Oct 23, 2019 at 10:42 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli at arm.com> wrote:
>
> On Wed, 23 Oct, 2019, 2:02 am Honnappa Nagarahalli, <Honnappa.Nagarahalli at arm.com> wrote:
>
> <snip>
>
> >
> > From: Jerin Jacob <jerinj at marvell.com>
> >
> > Update the armv8 crypto PMD maintainership.
> >
> > https://github.com/caviumnetworks/armv8_crypto external crypto the library
> > will not be maintained and probably removed soon therefor updating the PMD
> > documentation to reflect the same.
> >
> > Signed-off-by: Jerin Jacob <jerinj at marvell.com>
> > ---
> >
> > This patch is based on the discussion of the following thread
> > http://mails.dpdk.org/archives/dev/2019-October/146005.html
> >
> > In summary,
> > # ARMv8 crypto PMD depends on an external library owned by Marvell,
> > specifically crafted to the DPDK performance use case.
> > # There is no upstream path to this library and it will not be maintained due to
> > that fact that it
> > a) Creates fragmentation of the SW
> > b) Contribution policy concerning external Github Repos
> > c) None other than Marvell can contribute to this library and this makes
> > difficult for other stakeholder to use it.
> >
> > # As the maintainer, I would like to make forward progress by providing the
> > following options. None of the options are converging as the result I would like
> > to step down from the maintainership of the incomplete PMD as I don't see
> > any options for collaboration, improvement in the library nor follows the open
> > source philosophy in the way it is structured out now.
> >
> > option 1) Move external library(BSD-3 license) to dpdk.org so that every armv8
> > vendors can contribute, improve and avoid SW fragmentation and therefore
> > better quality.
> I do not see any issues with this approach. This patch should be changed to reflect this option?
>
>
>
>
>
> In past, there was a concern with this approach about maintaining the assembly code in dpdk.org. Is this concern still valid?
>
>
>
>
> >
> > option 2) If option 1 is not possible, remove the incomplete PMD from
> > dpdk.org and maintain the existing PMD as the external one by each vendor.
> > This won't change much in the existing situation as this PMD is not standalone
> > and anyway depended on an external code base.
> IMHO, DPDK defines an interface to integrate an external crypto library. This might be under use by applications. Removing the PMD will break those applications.
>
>
>
> DPDK does not define any such interface. It was pushed to external library for the reason mentioned above.
>
> [Honnappa] So, what should an application which has its own crypto library do when the PMD is removed?

Sorry. I missed this question. The reason why it was moved out, is not
to have N different crypto library and bind to this, instead of one
library where
everyone can contribute it.
and the interface between library and the PMD is not designed to
create a framework. It is crafted in the way, the "current"
external library needed and not for the generic case.