On Wed, Oct 23, 2019 at 10:42 PM Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> wrote: > > On Wed, 23 Oct, 2019, 2:02 am Honnappa Nagarahalli, > <honnappa.nagaraha...@arm.com> wrote: > > <snip> > > > > > From: Jerin Jacob <jer...@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 <jer...@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.
