From mboxrd@z Thu Jan 1 00:00:00 1970 From: Binoy Jayan Subject: Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Date: Wed, 1 Mar 2017 23:34:49 +0530 Message-ID: References: <1486463731-6224-1-git-send-email-binoy.jayan@linaro.org>

<68f70534-a309-46ba-a84d-8acc1e6620e5@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6998054475809986700==" Cc: Rajendra , Herbert Xu , Oded , Mike Snitzer , Linux kernel mailing list , Ondrej Mosnacek , linux-raid@vger.kernel.org, Gilad Ben-Yossef , dm-devel@redhat.com, Mark Brown , Arnd Bergmann , linux-crypto@vger.kernel.org, Shaohua Li , "David S. Miller" , Alasdair Kergon , Ofir To: Milan Broz Return-path: In-Reply-To: <68f70534-a309-46ba-a84d-8acc1e6620e5@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com List-Id: linux-crypto.vger.kernel.org --===============6998054475809986700== Content-Type: multipart/alternative; boundary=001a11457aae0e08070549af263a --001a11457aae0e08070549af263a Content-Type: text/plain; charset=UTF-8 Hi Milan, On 1 March 2017 at 02:35, Milan Broz 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 --001a11457aae0e08070549af263a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Milan,

On 1 March 2017 at 02:35, Milan Broz <gmazyland@gmail.com> wrote:

<= span class=3D"gmail-">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 IPSe= c offload?

I just tried this and except it registers the IV for every new devic= e 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 instan= ce every time by invoking the
".create" callback. I gue= ss it should be solved by adding test data to testmgr.

=
Do you have some real per= formance numbers that proves that such a patch is adequate?

While waiting to do some implementation of the hw cryp= to drivers to work with
dm-crypt, I'll also generate some num= bers to compare the performance with the
original dm-crypt code w= ith the new one with a software implementation in place.
=C2=A0
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 thi= s 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 generat= ors.

I think it should work for everyon= e (even for ciphers not supporting IVs) if the null IV
mode is us= ed. It should be upto the IV generation template to choose to generate IV
or just call the underlying (base) template/cipher.
=C2= =A0
Regards,
Binoy

<= /div>
--001a11457aae0e08070549af263a-- --===============6998054475809986700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6998054475809986700==--