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. > We do have a tfm pointer hanging off the inode (currently only used > for directories and file name encryption, where i_mutex is serializing > us anyway), and in theory we could use that for the data path as well. > We'd have to serialize access to it, which could be performance > problem, and if the tfm is significantly larger than the raw key, we'd > need to know when we should nuke the tfm. As long as an inode only has one key, you don't need any serialisation. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
