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 12:40:08AM -0500, Bob Pearson wrote:
Hi Darrick,
The same code in crc32.c was helpful to measure performance and help code
tuning as well as indicate correctness. Otherwise the code in crypto may be
enough to test all the corner cases. If this survives the review I
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:
Hi,
I’m doing some benchmarks of IPsec performance on Cisco router and I
have experienced the situation described below. My question is whether
anybody has performed similar tests on Linux (StrongSWAN, OpenSWAN,…)
or any other security gateway and can tell how did it behave.
When you are
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
On Thu, Sep 01, 2011 at 03:18:54PM -0700, Darrick J. Wong wrote:
I suspect it would be pretty easy to adapt the Makefile to generate the
relevant .c and .h files; in particular it could be useful to use the crypto
framework for crc32 on the off chance anyone wants to provide hwaccel for that
Add ctr(blowfish) speed test to receive results for blowfish x86_64 assembly
patch.
Signed-off-by: Jussi Kivilinna jussi.kivili...@mbnet.fi
---
crypto/tcrypt.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 617..e353a28
Patch splits up the blowfish crypto routine into a common part (key setup)
which will be used by blowfish crypto modules (x86_64 assembly and generic-c).
Also fixes errors/warnings reported by checkpatch.
Signed-off-by: Jussi Kivilinna jussi.kivili...@mbnet.fi
---
crypto/Kconfig|
Patch adds x86_64 assembly implementation of blowfish. Two set of assembler
functions are provided. First set is regular 'one-block at time'
encrypt/decrypt functions. Second is 'four-block at time' functions that
gain performance increase on out-of-order CPUs. Performance of 4-way
functions
Rename blowfish to blowfish_generic so that assembler versions of blowfish
cipher can autoload. Module alias 'blowfish' is added.
Also fix checkpatch warnings.
Signed-off-by: Jussi Kivilinna jussi.kivili...@mbnet.fi
---
crypto/Makefile |2 -
crypto/blowfish.c | 139
On Mon, Aug 29, 2011 at 10:18:18AM +0200, Steffen Klassert wrote:
On Mon, Aug 22, 2011 at 02:59:01PM +0800, Herbert Xu wrote:
On Wed, Aug 17, 2011 at 02:10:13PM +0200, Steffen Klassert wrote:
+struct crypto_user_alg {
+ char cru_name[CRYPTO_MAX_ALG_NAME];
+ char
19 matches
Mail list logo
