On 09/01/2011 04:15 AM, Herbert Xu wrote:
Nikos Mavrogiannopoulosn...@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
On Thu, Sep 01, 2011 at 08:26:07AM +0200, Nikos Mavrogiannopoulos wrote:
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
On 09/01/2011 08:43 AM, Herbert Xu wrote:
On Thu, Sep 01, 2011 at 08:26:07AM +0200, Nikos Mavrogiannopoulos wrote:
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
On Thu, Sep 01, 2011 at 08:54:19AM +0200, Nikos Mavrogiannopoulos wrote:
Have you actually measured that?
Not against your cryptodev code-base.
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Thu, Sep 1, 2011 at 4:14 PM, Herbert Xu herb...@gondor.hengli.com.au wrote:
Are you maxing out your submission CPU? If not then you're testing
the latency of the interface, as opposed to the throughput.
I think it is obvious that a benchmark of throughput measures
throughput. If however,
On Thu, Sep 1, 2011 at 4:59 PM, Herbert Xu herb...@gondor.hengli.com.au wrote:
latency, maybe(?) high throughput or so). Thus, I designed this
benchmark with a use-case in mind, i.e., a TLS or DTLS tunnel
executing in a system with such an accelerator. There might be other
benchmarks with
On Thu, Sep 01, 2011 at 05:06:06PM +0200, Nikos Mavrogiannopoulos wrote:
Indeed but today that's what we have in some systems. User-space TLS
implementations (GnuTLS and OpenSSL) and kernel-space crypto
offloading. The purpose of the /dev/crypto and AF_ALG interfaces is to
connect those
Herbert,
On Thu, Sep 01, 2011 at 10:14:45PM +0800, Herbert Xu wrote:
Phil Sutter p...@nwl.cc wrote:
chunksize af_alg cryptodev (100 * cryptodev / af_alg)
--
512 4.169 MB/s
On Thu, Sep 01, 2011 at 05:09:28PM +0200, Phil Sutter wrote:
Good point. So in order to also test the throughput, I've put my OpenRD
under load:
No that's not what I meant. You're pushing a request to an
async device and waiting for a response to come back before
pushing the next request. In
From: Nikos Mavrogiannopoulos n...@gnutls.org
Date: Thu, 1 Sep 2011 17:06:06 +0200
It would be interesting to have a partial kernel-space TLS
implementation but I don't know whether such a thing could ever make
it to kernel.
Herbert and I have discussed this several times and we plan on
On 09/01/2011 05:32 PM, David Miller wrote:
From: Nikos Mavrogiannopoulosn...@gnutls.org
Date: Thu, 1 Sep 2011 17:06:06 +0200
It would be interesting to have a partial kernel-space TLS
implementation but I don't know whether such a thing could ever make
it to kernel.
Herbert and I have
Nikos Mavrogiannopoulos n...@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
On 08/28/2011 10:35 PM, David Miller wrote:
The benchmark idea was to test the speed of initialization, encryption
and deinitiation, as well as the encryption speed alone. These are the
most common use cases of the frameworks (i.e. how they would be used
by a cryptographic library).
Be sure to
From: Nikos Mavrogiannopoulos n...@gnutls.org
Date: Mon, 29 Aug 2011 09:32:19 +0200
On 08/28/2011 10:35 PM, David Miller wrote:
The benchmark idea was to test the speed of initialization, encryption
and deinitiation, as well as the encryption speed alone. These are the
most common use cases
Hello,
I've compared the cryptodev [0] and AF_ALG interfaces in terms of
performance [1]. I've put the results, as well as the benchmarks used
in: http://home.gna.org/cryptodev-linux/comparison.html
The benchmark idea was to test the speed of initialization, encryption
and deinitiation, as well
From: Nikos Mavrogiannopoulos n...@gnutls.org
Date: Sun, 28 Aug 2011 15:17:00 +0200
The benchmark idea was to test the speed of initialization, encryption
and deinitiation, as well as the encryption speed alone. These are the
most common use cases of the frameworks (i.e. how they would be used
16 matches
Mail list logo
