From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by dpdk.org (Postfix) with ESMTP id 6AC772B95 for ; Tue, 11 Oct 2016 11:14:49 +0200 (CEST) Received: by mail-lf0-f43.google.com with SMTP id b81so31034596lfe.1 for ; Tue, 11 Oct 2016 02:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=VOg1kiXuyHllpNSIjvq/XACbi3pCzaPnfgLmzkC5rD0=; b=dsu/Yx7AQ5jnicU+LWn+KEo/DCVqfE9CvimHFu1LCC4jfrtoZ1ng0HRAtPQFAWusTZ yjIVpUmKQ/rWbX6o8rrVX3NIMrEqCS5yBaFuRUryF6O/3Jyj6b2zpNcne/YZ7hI+j8cC SU4gO0QrgZ/hclsILqdvkG9opjaZpmDMl0iqdUNloKXxyruWatPSmkwPHpLag54s51DD yzs3rZe76onKpmmNbqQ0P4ncN3kfZUnUFyokEqCUPs9i9V0HMoFPHmYXkrIL5GMqlPrS dNxA2DXpr6fZJLjKNCaUoy48ISEJPHPtWeULUo+7sn/GKn6wRFEBc6GlSec2msO8gEMZ 3IUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=VOg1kiXuyHllpNSIjvq/XACbi3pCzaPnfgLmzkC5rD0=; b=Ou1IUca/Mct0Q8jvUnH+6IHrfHRGa/IyhdmsFQBhUpokV3st3fx8XZ3MYIRToN+krN 0c2ZorDV15oj72Pdjxq/DDG73mPVYoq0HXpUiZaZ2+SSZSCLZigwF/EvjGiM01eGlYC7 MqOOJHZIYdpIZUBXTre0ek2/IcIvbBKxDg9xMGHSJgao8ryBpwT5SHqqnJIXh+eDXwJa Tn+bLwnGEAzAiTQH09VccoZycyIvfo+wbjfd/PED8+Z9O6xiol+XUPWMOlOAS4Vtin9I 4pIWxQVMS4gj75ZW+M6L5F8qEaP+wqMeic9s3dseqyobs8Kb2AapVRA3unpHeW3cEBzl AZig== X-Gm-Message-State: AA6/9Rno04lsVXUoXK4bL5O3wHOyYF6v0YxvXh5vT+gyWojRVGO9zJvRfCrpmn3xnqUPwUPf X-Received: by 10.46.32.200 with SMTP id g69mr1657120lji.49.1476177288911; Tue, 11 Oct 2016 02:14:48 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 198sm564853ljf.17.2016.10.11.02.14.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2016 02:14:47 -0700 (PDT) From: Thomas Monjalon To: Declan Doherty Cc: pablo.de.lara.guarch@intel.com, dev@dpdk.org Date: Tue, 11 Oct 2016 11:14:46 +0200 Message-ID: <3540712.3nQULOpVav@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2d5bb5ac-dd3a-19c7-9253-961110adc938@intel.com> References: <2254713.m5JxJRtkTJ@xps13> <2d5bb5ac-dd3a-19c7-9253-961110adc938@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] OpenSSL libcrypto PMD name X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 09:14:49 -0000 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 ;)