From: Baolin Wang Subject: Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag Date: Fri, 3 Jun 2016 16:15:28 +0800 Message-ID: References: <47e9ddd8c9ea9ad9e29c8cb027d19d8459ea1479.1464346333.git.baolin.wang@linaro.org> <20160602082606.GA15226@gondor.apana.org.au> <20160603065146.GA29953@gondor.apana.org.au> <20160603075435.GA30149@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Jens Axboe , Alasdair G Kergon , Mike Snitzer , "open list:DEVICE-MAPPER (LVM)" , David Miller , Eric Biggers , Joonsoo Kim , tadeusz.struk@intel.com, smueller@chronox.de, Masanari Iida , Shaohua Li , Dan Williams , "Martin K. Petersen" , Sagi Grimberg , Kent Overstreet , Keith Busch , Tejun Heo , Ming Lei , Mark Brown , Arnd Bergmann , linux-crypto@vger.kernel.org, linux-block@vger.kernel.org, "open list:SOFTWARE RAID (Multiple Disks) SUPPORT" , LKML Return-path: Received: from mail-yw0-f176.google.com ([209.85.161.176]:34546 "EHLO mail-yw0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750923AbcFCIPa (ORCPT ); Fri, 3 Jun 2016 04:15:30 -0400 Received: by mail-yw0-f176.google.com with SMTP id c127so73658901ywb.1 for ; Fri, 03 Jun 2016 01:15:29 -0700 (PDT) In-Reply-To: <20160603075435.GA30149@gondor.apana.org.au> Sender: linux-crypto-owner@vger.kernel.org List-ID: On 3 June 2016 at 15:54, Herbert Xu wrote: > On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote: >> On 3 June 2016 at 14:51, Herbert Xu wrote: >> > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote: >> >> >> >> If we move the IV generation into the crypto API, we also can not >> >> handle every algorithm with the bulk interface. Cause we also need to >> >> use different methods to map one whole bio or map one sector according >> >> to the algorithm whether can support bulk mode or not. Please correct >> >> me if I misunderstand your points. Thanks. >> > >> > Which ones can't be handled this way? >> >> What I mean is bulk mode and sector mode's difference is not only the >> IV handling method, but also the method to map the data with >> scatterlists. >> Then we have two processes in dm-crypt ( crypt_convert_block() and >> crypt_convert_bulk_block() ) to handle the data, so we can not handle >> every algorithm with the bulk interface. > > As I asked, which algorithm can't you handle through the bulk > interface, assuming it did all the requisite magic to generate > the correct IV? Suppose the cbc(aes) algorithm, which can not be handled through bulk interface, it need to map the data sector by sector. If we also handle the cbc(aes) algorithm with bulk interface, we need to divide the sg table into sectors and need to allocate request memory for each divided sectors (As Mike pointed out this is in the IO mapping path and we try to avoid memory allocations at all costs -- due to the risk of deadlock when issuing IO to stacked block devices (dm-crypt could be part of a much more elaborate IO stack). ), that will introduce more messy things I think. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards