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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 10/23/2019 7:17 PM, Honnappa Nagarahalli wrote:
>>>> From: Jerin Jacob <jerinj@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@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 <jerinj@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