From: Ben Greear <greearb@candelatech.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH 0/5] crypto: Implement cmac based on cbc skcipher
Date: Thu, 20 Aug 2020 15:09:55 -0700 [thread overview]
Message-ID: <af57bfe4-87cf-1862-356d-970b41678c8e@candelatech.com> (raw)
In-Reply-To: <20200820201055.GA24119@gondor.apana.org.au>
On 8/20/20 1:10 PM, Herbert Xu wrote:
> On Thu, Aug 20, 2020 at 06:54:58AM -0700, Ben Greear wrote:
>>
>> Here's a run on an: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
>>
>> testing speed of async cmac(aes-aesni) (cmac(aes-aesni))
>>
>> [ 259.397910] tcrypt: test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 8442 cycles/operation, 8 cycles/byte
>>
>> testing speed of async cmac(aes-generic) (cmac(aes-generic))
>>
>> [ 294.171530] tcrypt: test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 9022 cycles/operation, 8 cycles/byte
>>
>> On my slow apu2 board with processor: AMD GX-412TC SOC
>>
>> testing speed of async cmac(aes-aesni) (cmac(aes-aesni))
>>
>> [ 51.751810] tcrypt: test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 18759 cycles/operation, 18 cycle
>>
>> testing speed of async cmac(aes-generic) (cmac(aes-generic))
>>
>> [ 97.837497] tcrypt: test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 31365 cycles/operation, 30 cycle
>
> So clearly aes-generic is slower than aes-aesni even with saving and
> restoring for each block. Therefore improving the performance of
> the latter per se does not make sense.
I have always assumed that I need aesni instructions to have any chance at this performing well,
but there are certainly chips out there that don't have aesni, so possibly it is still worth improving
if it is relatively easy to do so.
I am currently using x86-64 CPUs with aesni, and also some AP platforms running QCA ARM chips.
I am not sure if ARM is using aesni or not...it is certainly not that fast, but maybe for other
reasons.
Thanks,
Ben
>
> Cheers,
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2020-08-20 22:10 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-02 9:06 [PATCH] crypto: x86/aesni - implement accelerated CBCMAC, CMAC and XCBC shashes Ard Biesheuvel
2020-08-03 19:11 ` Ben Greear
2020-08-04 12:55 ` Ard Biesheuvel
2020-08-04 13:01 ` Ben Greear
2020-08-04 13:08 ` Ard Biesheuvel
2020-08-04 13:22 ` Ben Greear
2020-08-04 19:45 ` Ben Greear
2020-08-04 20:12 ` Ard Biesheuvel
2020-09-23 11:03 ` Ben Greear
2020-10-29 16:58 ` Ard Biesheuvel
2020-08-18 8:24 ` [PATCH 0/5] crypto: Implement cmac based on cbc skcipher Herbert Xu
2020-08-18 8:25 ` [PATCH 1/6] crypto: skcipher - Add helpers for sync skcipher spawn Herbert Xu
2020-08-18 8:25 ` [PATCH 2/6] crypto: ahash - Add helper to free single spawn instance Herbert Xu
2020-08-18 8:25 ` [PATCH 3/6] crypto: ahash - Add init_tfm/exit_tfm Herbert Xu
2020-08-18 8:25 ` [PATCH 4/6] crypto: ahash - Add ahash_alg_instance Herbert Xu
2020-08-18 8:25 ` [PATCH 5/6] crypto: ahash - Remove AHASH_REQUEST_ON_STACK Herbert Xu
2020-08-26 10:55 ` Ard Biesheuvel
2020-08-18 8:25 ` [PATCH 6/6] crypto: cmac - Use cbc skcipher instead of raw cipher Herbert Xu
2020-08-24 9:47 ` Ard Biesheuvel
2020-08-24 11:20 ` Herbert Xu
2020-08-18 8:31 ` [PATCH 0/5] crypto: Implement cmac based on cbc skcipher Ard Biesheuvel
2020-08-18 13:51 ` Herbert Xu
2020-08-18 13:56 ` Ben Greear
2020-08-18 14:05 ` Herbert Xu
2020-08-18 14:17 ` Ben Greear
2020-08-18 22:15 ` Herbert Xu
2020-08-18 22:27 ` Herbert Xu
2020-08-18 22:31 ` Ben Greear
2020-08-18 22:33 ` Herbert Xu
2020-08-18 22:39 ` Ben Greear
2020-08-20 6:58 ` Ard Biesheuvel
2020-08-20 7:01 ` Herbert Xu
2020-08-20 7:04 ` Ard Biesheuvel
2020-08-20 7:06 ` Herbert Xu
2020-08-20 7:19 ` Ard Biesheuvel
2020-08-20 7:29 ` Herbert Xu
2020-08-20 7:33 ` Ard Biesheuvel
2020-08-20 7:44 ` Herbert Xu
2020-08-20 7:48 ` Ard Biesheuvel
2020-08-20 7:53 ` Herbert Xu
2020-08-20 7:56 ` Ard Biesheuvel
2020-08-20 13:54 ` Ben Greear
2020-08-20 20:10 ` Herbert Xu
2020-08-20 22:09 ` Ben Greear [this message]
2020-08-20 22:12 ` Herbert Xu
2020-08-22 22:35 ` Christian Lamparter
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=af57bfe4-87cf-1862-356d-970b41678c8e@candelatech.com \
--to=greearb@candelatech.com \
--cc=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@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 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).