Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752832AbbKLCPg (ORCPT ); Wed, 11 Nov 2015 21:15:36 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:34448 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752513AbbKLCPf (ORCPT ); Wed, 11 Nov 2015 21:15:35 -0500 MIME-Version: 1.0 In-Reply-To: <20151111094811.GA3641@infradead.org> References: <20151111094811.GA3641@infradead.org> Date: Thu, 12 Nov 2015 10:15:32 +0800 Message-ID: Subject: Re: [PATCH 0/2] Introduce the request handling for dm-crypt From: Baolin Wang To: Christoph Hellwig Cc: axboe@kernel.dk, agk@redhat.com, snitzer@redhat.com, dm-devel@redhat.com, neilb@suse.com, jack@suse.cz, tj@kernel.org, jmoyer@redhat.com, keith.busch@intel.com, bart.vanassche@sandisk.com, linux-raid@vger.kernel.org, Mark Brown , Arnd Bergmann , "Garg, Dinesh" , 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 Content-Length: 1788 Lines: 35 On 11 November 2015 at 17:48, Christoph Hellwig wrote: > On Wed, Nov 11, 2015 at 05:31:43PM +0800, Baolin Wang wrote: >> Now the dm-crypt code only implemented the 'based-bio' method to encrypt/ >> decrypt block data, which can only hanle one bio at one time. As we know, >> one bio must use the sequential physical address and it also has a limitation >> of length. Thus it may limit the big block encyrtion/decryption when some >> hardware support the big block data encryption. >> >> This patch series introduc the 'based-request' method to handle the data >> encryption/decryption. One request can contain multiple bios, so it can >> handle big block data to improve the efficiency. > > NAK for more request based stacking or DM drivers. They are a major > pain to deal with, and adding more with different requirements then > dm-multipath is not helping in actually making that one work properly. But now many vendors supply the hardware engine to handle the encyrtion/decryption. The hardware really need a big block to indicate its performance with request based things. Another thing is now the request based things is used by many vendors (Qualcomm, Spreadtrum and so on) to improve their performance and there's a real performance requirement here (I can show the performance result later). I don't think you will worry if any one can work properly, we will remove the bio based things in future if the request things are accepted and proved effectively. Thanks for your comment. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/