From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Herbert Xu <herbert@gondor.hengli.com.au>
Cc: cryptodev-linux-devel@gna.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: comparison of the AF_ALG interface with the /dev/crypto
Date: Thu, 01 Sep 2011 08:26:07 +0200 [thread overview]
Message-ID: <4E5F257F.9060202@gnutls.org> (raw)
In-Reply-To: <20110901021534.GA26330@gondor.apana.org.au>
On 09/01/2011 04:15 AM, Herbert Xu wrote:
> Nikos Mavrogiannopoulos<nmav@gnutls.org> wrote:
>>
>> Given my benchmarks have no issues, it is not apparent to me why one
>> should use AF_ALG instead of cryptodev. I do not know though why AF_ALG
>> performs so poor. I'd speculate by blaming it on the usage of the socket
>> API and the number of system calls required.
> The target usage of AF_ALG is hardware offload devices that cannot
> be directly used in user-space, not software crypto on implementations
> such as AESNI/Padlock.
> Going through the kernel to use something like AESNI/Padlock or
> software crypto is insane.
> Given the intended target case, your numbers are pretty much
> meaningless as cryptodev's performance can be easily beaten
> by a pure user-space implementation.
Actually this is the reason of the ecb(cipher-null) comparison. To
emulate the case of a hardware offload device. I tried to make that
clear in the text, but may not be. If you see AF_ALG performs really bad
on that case. It performs better when a software or a padlock
implementation of AES is involved (which as you say it is a useless
use-case).
Of course, I don't own such an offloading device and cannot test it
directly. If you have different values from a benchmark with an actual
hardware accelerator, I'll be happy to include them.
regards,
Nikos
next prev parent reply other threads:[~2011-09-01 6:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-28 13:17 comparison of the AF_ALG interface with the /dev/crypto Nikos Mavrogiannopoulos
2011-08-28 20:35 ` David Miller
2011-08-29 7:32 ` Nikos Mavrogiannopoulos
2011-08-29 16:09 ` David Miller
2011-08-30 16:33 ` [Cryptodev-linux-devel] " Phil Sutter
2011-09-01 2:15 ` Herbert Xu
2011-09-01 2:15 ` Herbert Xu
2011-09-01 6:26 ` Nikos Mavrogiannopoulos [this message]
2011-09-01 6:43 ` Herbert Xu
2011-09-01 6:43 ` Herbert Xu
2011-09-01 6:54 ` Nikos Mavrogiannopoulos
2011-09-01 6:56 ` Herbert Xu
2011-09-01 6:56 ` Herbert Xu
2011-09-01 13:39 ` Phil Sutter
2011-09-01 13:39 ` Phil Sutter
2011-09-01 14:14 ` Herbert Xu
2011-09-01 14:14 ` Herbert Xu
2011-09-01 14:56 ` Nikos Mavrogiannopoulos
2011-09-01 14:59 ` Herbert Xu
2011-09-01 14:59 ` Herbert Xu
2011-09-01 15:06 ` Nikos Mavrogiannopoulos
2011-09-01 15:08 ` Herbert Xu
2011-09-01 15:08 ` Herbert Xu
2011-09-01 15:32 ` David Miller
2011-09-01 16:19 ` Nikos Mavrogiannopoulos
2011-09-01 15:09 ` Phil Sutter
2011-09-01 15:09 ` Phil Sutter
2011-09-01 15:13 ` Herbert Xu
2011-09-01 15:13 ` Herbert Xu
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=4E5F257F.9060202@gnutls.org \
--to=nmav@gnutls.org \
--cc=cryptodev-linux-devel@gna.org \
--cc=herbert@gondor.hengli.com.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.