Thread (6 messages) 6 messages, 2 authors, 2015-12-02

Re: [PATCH v3 5/5] crypto: AES CBC multi-buffer glue code

From: Tim Chen <hidden>
Date: 2015-12-02 20:04:03
Also in: lkml

On Tue, 2015-12-01 at 09:19 -0800, Tim Chen wrote:
On Thu, 2015-11-26 at 16:49 +0800, Herbert Xu wrote:
quoted
On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote:
quoted
On the decrypt path, we don't need to use multi-buffer algorithm
as aes-cbc decrypt can be parallelized inherently on a single
request.  So most of the time the outer layer algorithm
cbc_mb_async_ablk_decrypt can bypass mcryptd and
invoke mb_aes_cbc_decrypt synchronously
to do aes_cbc_dec when fpu is available.
This avoids the overhead of going through mcryptd.  Hence
the use of blkcipher on the inner layer.  For the mcryptd
path, we will complete a decrypt request in one shot so
blkcipher usage should be fine.
I think there is a misunderstanding here.  Just because you're
using/exporting through the ablkcipher interface doesn't mean
that you are asynchrounous.  For example, all blkcipher algorithms
can be accessed through the ablkcipher interface and they of course
remain synchrounous.

So I don't see how using an ablkcipher in the inner layer changes
anything at all.  You can still return immediately and not bother
with completion functions when you are synchrounous.

Cheers,
OK, I'll try to see if I can cast things back to the original ablkcipher
request and use that to walk the sg list.
Herbert,

I've sent out a new version of this series to use ablkcipher on the
inner layer of decrypt.  Thanks.

Tim
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help