On Fri, Feb 21, 2020 at 10:34:37AM -0800, Eric Biggers wrote: > On Fri, Feb 21, 2020 at 09:35:39AM -0800, Christoph Hellwig wrote: > > High-level question: Does the whole keyslot manager concept even make > > sense for the fallback? With the work-queue we have item that exectutes > > at a time per cpu. So just allocatea per-cpu crypto_skcipher for > > each encryption mode and there should never be a slot limitation. Or > > do I miss something? > > It does make sense because if blk-crypto-fallback didn't use a keyslot > manager, > it would have to call crypto_skcipher_setkey() on the I/O path for every bio > to > ensure that the CPU's crypto_skcipher has the correct key. That's > undesirable, > because setting a new key can be expensive with some encryption algorithms, > and > also it can require a memory allocation which can fail. For example, with the > Adiantum algorithm, setting a key requires encrypting ~1100 bytes of data in > order to generate subkeys. It's better to set a key once and use it many > times.
I didn't think of such expensive operations when setting the key. Note that you would not have to do it on every I/O, as chances are high you'll get I/O from the same submitter and thus the same key, and we can optimize for that case pretty easily. But if you think the keyslot manager is better I accept that, this was just a throught when looking over the code. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
