On 20 July 2018 at 00:50, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Jul 19, 2018 at 11:08:52PM +0900, Ard Biesheuvel wrote: > >> But this will only be the case if the accelerator is capable of doing >> the IV generation and en/decryption of multiple contiguous sectors in >> a single call. Otherwise, you are just shifting work from one layer to >> the next. > >> So at this point, it would be useful to clarify what exactly these >> accelerators are doing and how. > > Existing hardware can definitely do the IV generation and I believe that > it can chain multiple sectors together though I'd need to confirm this, > as mentioned elsewhere in the thread the ccree driver is for one of > the relevant devices. I've poked some relevant people. As far as I can infer from the ccree driver source, IV generation and en/decryption are separate operations, and given that each sector requires both operations to be applied in sequence, letting the crypto layer handle an entire bio does not have any benefit *at the moment*. In fact, it seems to me that the ability to use protected AES keys is much more appealing than any performance argument (including 'it may be slower but at least it does not load the CPU'), so some background on how such a change would enable this use case would be beneficial as well to getting this adopted. So my recommendation would be to focus on moving the IV generation into the crypto layer, but conservatively, and not confuse people by making additional changes that could theoretically improve performance, but only on hardware that does not exist. -- Ard. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
