DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Declan Doherty <declan.doherty@intel.com>
Cc: pablo.de.lara.guarch@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] OpenSSL libcrypto PMD name
Date: Tue, 11 Oct 2016 11:14:46 +0200	[thread overview]
Message-ID: <3540712.3nQULOpVav@xps13> (raw)
In-Reply-To: <2d5bb5ac-dd3a-19c7-9253-961110adc938@intel.com>

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 ;)

      reply	other threads:[~2016-10-11  9:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-10 11:36 Thomas Monjalon
2016-10-11  8:53 ` Declan Doherty
2016-10-11  9:14   ` Thomas Monjalon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3540712.3nQULOpVav@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=pablo.de.lara.guarch@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).