Hi Milan,
On 1 March 2017 at 02:35, Milan Broz <gmazyland@xxxxxxxxx> wrote:
On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>
> I was wondering if this is near to be ready for submission (apart from
> the testmgr.c
> changes) or I need to make some changes to make it similar to the IPSec offload?
I just tried this and except it registers the IV for every new device again, it works...
(After a while you have many duplicate entries in /proc/crypto.)
It is because the the crypto lookup api sees that the crypto algorithm is in
a LARVAL state and registers a new instance every time by invoking the
".create" callback. I guess it should be solved by adding test data to testmgr.
Do you have some real performance numbers that proves that such a patch is adequate?
While waiting to do some implementation of the hw crypto drivers to work with
dm-crypt, I'll also generate some numbers to compare the performance with the
original dm-crypt code with the new one with a software implementation in place.
I would really like to see the performance issue fixed but I am really not sure
this approach works for everyone. It would be better to avoid repeating this exercise later.
IIRC Ondra's "bulk" mode, despite rejected, shows that there is a potential
to speedup things even for crypt drivers that do not support own IV generators.
I think it should work for everyone (even for ciphers not supporting IVs) if the null IV
mode is used. It should be upto the IV generation template to choose to generate IV
or just call the underlying (base) template/cipher.
Regards,
Binoy
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
