From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751632AbcFCGsi (ORCPT ); Fri, 3 Jun 2016 02:48:38 -0400 Received: from mail-yw0-f177.google.com ([209.85.161.177]:35206 "EHLO mail-yw0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751082AbcFCGsf (ORCPT ); Fri, 3 Jun 2016 02:48:35 -0400 MIME-Version: 1.0 In-Reply-To: <20160602082606.GA15226@gondor.apana.org.au> References: <47e9ddd8c9ea9ad9e29c8cb027d19d8459ea1479.1464346333.git.baolin.wang@linaro.org> <20160602082606.GA15226@gondor.apana.org.au> From: Baolin Wang Date: Fri, 3 Jun 2016 14:48:34 +0800 Message-ID: Subject: Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag To: Herbert Xu 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Herbet, On 2 June 2016 at 16:26, Herbert Xu wrote: > On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote: >> Now some cipher hardware engines prefer to handle bulk block rather than one >> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle >> the intermediate values (IV) by themselves in one bulk block. This means we >> can increase the size of the request by merging request rather than always 512 >> bytes and thus increase the hardware engine processing speed. >> >> So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk >> mode. >> >> Signed-off-by: Baolin Wang > > I think a better aproach would be to explicitly move the IV generation > into the crypto API, similar to how we handle IPsec. Once you do > that then every algorithm can be handled through the bulk interface. > Sorry for late reply. 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. > 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