[dpdk-dev] OpenSSL libcrypto PMD name

[dpdk-dev] OpenSSL libcrypto PMD name

[Thomas Monjalon]

Hi,

I would like to raise a naming issue in crypto.

In the crypto side of DPDK, we have a library (similar to ethdev)
for crypto API and device interface:
	http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev
There are also some drivers (which are some libraries):
	http://dpdk.org/browse/dpdk/tree/drivers/crypto
Most of them (6/8) are some DPDK wrappers for external libraries.

Recently was introduced the libcrypto PMD which is a wrapper for
the OpenSSL libcrypto.
As we already have a lot of crypto libraries, I'm afraid the name
libcrypto is really confusing. Why not call it openssl PMD?

PS: I know OpenSSL has 2 libraries - ssl and crypto - but I do not
expect any high-level SSL feature in a crypto driver.
So drivers/crypto/openssl should not be confusing.

Re: [dpdk-dev] OpenSSL libcrypto PMD name

[Declan Doherty]

On 10/10/16 12:36, Thomas Monjalon wrote:
> Hi,
>
> I would like to raise a naming issue in crypto.
>
> In the crypto side of DPDK, we have a library (similar to ethdev)
> for crypto API and device interface:
> 	http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev
> There are also some drivers (which are some libraries):
> 	http://dpdk.org/browse/dpdk/tree/drivers/crypto
> Most of them (6/8) are some DPDK wrappers for external libraries.
>
> Recently was introduced the libcrypto PMD which is a wrapper for
> the OpenSSL libcrypto.
> As we already have a lot of crypto libraries, I'm afraid the name
> libcrypto is really confusing. Why not call it openssl PMD?
>
> PS: I know OpenSSL has 2 libraries - ssl and crypto - but I do not
> expect any high-level SSL feature in a crypto driver.
> So drivers/crypto/openssl should not be confusing.
>


Hey Thomas,

I can see the how this could get pretty confusion especially to those 
not familiar with the implementation details. I think the current name 
makes sense using the rational that we are only using the libcrypto 
library from openssl and not libssl but it doesn't make things exactly 
clear within DPDK.

My thought is that we could just call the PMD "base_sw", as this is the 
function which it is intended to provide, a base implementation of 
algorithms for which there isn't an optimized/vectorised software 
implementation or a fall back for systems which don't support the 
required vector or CPU instructions for the optimized libraries. Also 
this would allow us at a later date extend beyond the scope of Openssl 
if required.

Declan

Re: [dpdk-dev] OpenSSL libcrypto PMD name

[Thomas Monjalon]

2016-10-11 09:53, Declan Doherty:
> On 10/10/16 12:36, Thomas Monjalon wrote:
> > Hi,
> >
> > I would like to raise a naming issue in crypto.
> >
> > In the crypto side of DPDK, we have a library (similar to ethdev)
> > for crypto API and device interface:
> > 	http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev
> > There are also some drivers (which are some libraries):
> > 	http://dpdk.org/browse/dpdk/tree/drivers/crypto
> > Most of them (6/8) are some DPDK wrappers for external libraries.
> >
> > Recently was introduced the libcrypto PMD which is a wrapper for
> > the OpenSSL libcrypto.
> > As we already have a lot of crypto libraries, I'm afraid the name
> > libcrypto is really confusing. Why not call it openssl PMD?
> >
> > PS: I know OpenSSL has 2 libraries - ssl and crypto - but I do not
> > expect any high-level SSL feature in a crypto driver.
> > So drivers/crypto/openssl should not be confusing.
> 
> 
> Hey Thomas,
> 
> I can see the how this could get pretty confusion especially to those 
> not familiar with the implementation details. I think the current name 
> makes sense using the rational that we are only using the libcrypto 
> library from openssl and not libssl but it doesn't make things exactly 
> clear within DPDK.
> 
> My thought is that we could just call the PMD "base_sw", as this is the 
> function which it is intended to provide, a base implementation of 
> algorithms for which there isn't an optimized/vectorised software 
> implementation or a fall back for systems which don't support the 
> required vector or CPU instructions for the optimized libraries. Also 
> this would allow us at a later date extend beyond the scope of Openssl 
> if required.

Ah, I'm remembering that before creating a new library we should impose
to define the scope first :)
There are already some PMDs using other libraries.
Do you really want to extend this one beyond of OpenSSL? It looks a weird
use case to me. The question is: how do we choose a crypto library rather
than another one?

By the way, the name "base_sw" is worst :) Please call a marketing-qualified
person ;)