[dpdk-dev] [PATCH v2 00/12] Add crypto PMD optimized for ARMv8

Declan Doherty declan.doherty at intel.com
Wed Dec 21 16:34:14 CET 2016


On 08/12/16 17:45, Jerin Jacob wrote:
> On Thu, Dec 08, 2016 at 12:32:52PM +0100, Zbigniew Bodek wrote:
>> On 08.12.2016 11:24, Bruce Richardson wrote:
>>> On Tue, Dec 06, 2016 at 06:32:53PM -0800, zbigniew.bodek at caviumnetworks.com wrote:
>>>> From: Zbigniew Bodek <zbigniew.bodek at caviumnetworks.com>
>>>>
>>>> Introduce crypto poll mode driver using ARMv8
>>>> cryptographic extensions. This PMD is optimized
>>>> to provide performance boost for chained
>>>> crypto operations processing, such as:
>>>> * encryption + HMAC generation
>>>> * decryption + HMAC validation.
>>>> In particular, cipher only or hash only
>>>> operations are not provided.
>>>> Performance gain can be observed in tests
>>>> against OpenSSL PMD which also uses ARM
>>>> crypto extensions for packets processing.
>>>>
>>> Hi,
>>>
>>> great to see more crypto drivers coming into DPDK, thanks.
>>>
>>> Question: do you know if this code would have any export compliance
>>> implications for DPDK - or for those repackaging DPDK? Up till now, all
>>> the crypto code used by DPDK was actually packaged in separate libraries
>>> that were re-used, meaning that DPDK didn't contain any crypto
>>> algorithms itself.
>>>
>>
>> Hello Bruce,
>>
>> I don't know to be honest. I didn't know the reasoning behind not including
>> crypto code for Intel for example. I thought it was due to licensing and
>> code control rather than export compliance.
>>
>> Maybe someone from the DPDK community will know what are the constraints
>> related to including crypto algorithms to DPDK.
>
> One of the primary reason why we thought of going with this approach is
> for out of the box "distribution" enablement. We thought, if the core crypto
> algorithm sits in some git-hub code or public hosted tarball then the
> PMD will never be added to standard distributions and which is a setback
> for armv8 server ecosystem.
>
> Having said that and as Zbigniew mentioned, We are open for revisiting
> the crypto core algorithm and PMD split if there are community concerns
> about export compliance. Let us know.
>
> Jerin
>
>>
>> Kind regards
>> Zbigniew

Hey Jerin/Zbigniew,


as Bruce said it's great to see you contributing to the crypto ecosystem 
in DPDK. I don't know if the export compliance with the core crypto code 
is an issue or not, that's definitely not my area of expertise, but I do 
have some concern which I think it relates somewhat to Thomas questions 
regarding implementing the core crypto algorithms in C rather than assembly.

I wonder is there the expertise within the DPDK community to 
review/maintain the core crypto code in terms of both the assembly code 
itself and also the details of the crypto algorithm's implementations 
themselves. I know I wouldn't feel I have the knowledge/expertise to be 
able to review the core crypto algorithm's implementations and the 
assembly code itself and sign-off on them.

I understand the advantage of having the code integrated directly into 
DPDK for packaging etc but this also puts the ownest on the DPDK 
community for the correctness of the underlying implementation of a 
particular algorithm. I think the approach of a separate library removes 
this responsibility from the community and places it on the distributor 
of the core crypto library.

Declan




More information about the dev mailing list