-crypto@vger.kernel.org; Rajendra; Linux kernel mailing list;
linux-r...@vger.kernel.org; Shaohua Li; Mike Snitzer
Subject: Re: dm-crypt optimization
On Thu, Dec 22, 2016 at 01:55:59PM +0530, Binoy Jayan wrote:
>>
>> > Support of bigger block sizes would be unsafe without additional
On Thu, Dec 22, 2016 at 01:55:59PM +0530, Binoy Jayan wrote:
>
> > Support of bigger block sizes would be unsafe without additional mechanism
> > that provides
> > atomic writes of multiple sectors. Maybe it applies to 4k as well on some
> > devices though...)
>
> Did you mean write to the crypt
Hi Milan,
On 21 December 2016 at 18:17, Milan Broz wrote:
> So the core problem is that your crypto accelerator can operate efficiently
> only
> with bigger batch sizes.
Thank you for the reply. Yes, that would be rather an improvement when having
bigger block sizes.
> How big blocks your cry
On 12/20/2016 10:41 AM, Binoy Jayan wrote:
> At a high level the goal is to maximize the size of data blocks that get
> passed
> to hardware accelerators, minimizing the overhead from setting up and tearing
> down operations in the hardware. Currently dm-crypt itself is a big blocker as
> it manua
At a high level the goal is to maximize the size of data blocks that get passed
to hardware accelerators, minimizing the overhead from setting up and tearing
down operations in the hardware. Currently dm-crypt itself is a big blocker as
it manually implements ESSIV and similar algorithms which allo
