On Tue, May 19, 2015 at 10:27:55PM +0800, Herbert Xu wrote:

On Tue, May 19, 2015 at 10:14:30AM -0400, Theodore Ts'o wrote:

quoted

There can be multiple reads going on in parallel, so we're currently
creating tfm's as necessary.  In fact one of the things that we've

A single tfm is fully-reentrant (as long as you don't change the
key).  So multiple reads/writes on a single file can all use one
tfm with no locking at all.

There should be a single tfm per key.  As your code appears to use
one key per inode, that translates to one tfm per inode.

quoted

talked about doing is since there are some ARM cores where their
"hardware acceleration" is slower than optimized software (sigh), and
there are some Android applications (such as Facebook) that read
*vast* quantities of data from flash on startup before painting a
single pixel, that we might want to consider in some cases,
parallelizing the decryption across multiple ARM cores.  Figuring out
when to do this, both in terms of the workload, how many cores to use
to balance off against power utilization, how much (if ever) to use
the hardware "accelerator", and just plain lack of time caused us not
to go down that particular path.

We already have some support for such parallelisation in the form of
pcrypt.  It has been used on IPsec and I believe dmcrypt.

The current pcrypt version is used just for IPsec because it supports
only AEAD type algorithms and does not support request backlog. But
I have patches to support ablkcipher algorithms and request backlog.
I could provide them if there is interest in it.