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.bo...@caviumnetworks.com
wrote:
From: Zbigniew Bodek <zbigniew.bo...@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
