On Wed, Dec 21, 2016 at 03:34:14PM +0000, Declan Doherty wrote:

On 08/12/16 17:45, Jerin Jacob wrote:

quoted

On Thu, Dec 08, 2016 at 12:32:52PM +0100, Zbigniew Bodek wrote:

quoted

On 08.12.2016 11:24, Bruce Richardson wrote:

quoted

On Tue, Dec 06, 2016 at 06:32:53PM -0800, zbigniew.bodek@caviumnetworks.com wrote:

quoted

From: Zbigniew Bodek <redacted>

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

quoted

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.

OK. Taking Thomas and your feedback into account, We will move the core
crypto ARMv8 ASM code to separate library.

Jerin

Declan