On 10/23/2019 7:17 PM, Honnappa Nagarahalli wrote: >>>> 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? >>> >>> >>> >>> If no one is ready to host the actual code, how is even possible to have >> floating PMD which can not even build by community. >>> >>> [Honnappa] I am trying to understand your comment. Are you saying without >> the actual crypto library how do we build/test the PMD? >> >> Yes. >> >>> Is it ok to introduce a stub library which is used if >> ‘ARMV8_CRYPTO_LIB_PATH’ is not set. Such stub should not be subjected to >> export license issues. >> >> It won't be even functional. Right? and we really don't know, do we really >> have >> an export license issue or not? > Agree, stub is to just ensure that the PMD to lib interface is functional. > The export license issue need to be explored. Does this need to go to LF > legal?
Hi Honnappa, et al, Intel has a serious concern that including crypto code may cause restrictions on Intel contributions, this is under investigation. Also another major concern that, this may limit some consumers/users to access to the dpdk and/or use it. > >> >> Having said that, I have no issues if we choose to go with stub model >> provided >> this document patch is accepted. > Stub should be the last option, only if we run out of other options as it > will preserve only the PMD in DPDK. > IMO, we still have not reached a conclusion. I think following questions need > to be answered: > 1) The discussion on whether it should be part of DPDK still not concluded > (export license issues should come after this) > 2) What are the export licensing issues in the context of DPDK as an open > source project? > 3) Can it be a 'hosted-project' (similar to pkt-gen etc)? > >> >>> >>> >>> >>> I propose to take this to TB to reach to consensus as we are going in >>> circles in >> mailing list. >>> >>> >>> >>> >>> >>> >>>> >>>> I am glad/help to execute option 1 or 2 or help to a new maintainer >>>> if he/she would like to step up and take ownership. >>>> >>>> --- >>>> MAINTAINERS | 1 - >>>> doc/guides/cryptodevs/armv8.rst | 3 +-- >>>> 2 files changed, 1 insertion(+), 3 deletions(-) >>>> >>>> diff --git a/MAINTAINERS b/MAINTAINERS index b02066270..8096d93c4 >>>> 100644 >>>> --- a/MAINTAINERS >>>> +++ b/MAINTAINERS >>>> @@ -918,7 +918,6 @@ F: doc/guides/cryptodevs/ccp.rst >>>> F: doc/guides/cryptodevs/features/ccp.ini >>>> >>>> ARMv8 Crypto >>>> -M: Jerin Jacob <jer...@marvell.com> >>>> F: drivers/crypto/armv8/ >>>> F: doc/guides/cryptodevs/armv8.rst >>>> F: doc/guides/cryptodevs/features/armv8.ini >>>> diff --git a/doc/guides/cryptodevs/armv8.rst >>>> b/doc/guides/cryptodevs/armv8.rst index 1ab40096e..ada2a774d 100644 >>>> --- a/doc/guides/cryptodevs/armv8.rst >>>> +++ b/doc/guides/cryptodevs/armv8.rst >>>> @@ -28,8 +28,7 @@ Installation >>>> >>>> In order to enable this virtual crypto PMD, user must: >>>> >>>> -* Download ARMv8 crypto library source code from >>>> - `here <https://github.com/caviumnetworks/armv8_crypto>`_ >>>> +* Use ARMv8 crypto library source code from vendor SDK >>>> >>>> * Export the environmental variable ARMV8_CRYPTO_LIB_PATH with >>>> the path where the ``armv8_crypto`` library was downloaded >>>> -- >>>> 2.23.0
