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: > > > > 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. > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
