From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f8Pqp9ubCzD for ; Tue, 22 Jan 2013 08:24:36 +0100 (CET) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 22 Jan 2013 08:24:35 +0100 (CET) Received: by mail-wi0-f169.google.com with SMTP id hq12so3088249wib.0 for ; Mon, 21 Jan 2013 23:24:34 -0800 (PST) Message-ID: <50FE3EAF.3070206@gmail.com> Date: Tue, 22 Jan 2013 08:24:31 +0100 From: Milan Broz MIME-Version: 1.0 References: <20130122054223.GA25850@tansi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Encrypting with larger packet size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dinesh Garg Cc: dm-crypt@saout.de On 01/22/2013 07:04 AM, Dinesh Garg wrote: > I want to use hardware based crypto engine which would provide better > encryption/decryption throughput when packet sizes are bigger. If we > invoke hardware based crypto engine for every 512 bytes, there is so > much time spent in setting up cipher context in that throughput > becomes very less. Sorry, but fixing hw accelerator issues in sw is not reason for me. But anyway, if you search archive (just one month ago) I replied here mentioning the real problem with such change http://www.saout.de/pipermail/dm-crypt/2012-December/002917.html The real problem with allowing larger sector sizes is not in patch (it is quite simple in fact) but in incompatibility it causes (DM operates on 512 sector block level, LUKS metadata is not ready for this etc.) I still think that proper crypto hw accelerator should work even with these small blocks (scatter-gather lists to offload multiple buffers and operate in batch mode or whatever. If re-setting IV for crypto context eat so much time, something is wrong). Kernel crypto API provides api for async crypto drivers already. But my reply still applies - it is on TODO list but I would like to see some real world example, where we really need this. (Like some on-disk encryption format which require such operation and we would like to have support for it in Linux.) > Thats why I was thinking if I can contribute to dm-crypt where it can > accept larger packet sizes, it would be great for hardware based > crypto engine solution. > > HW based crypto engine outperforms the SW based when packet size > reaches 8K. For your particular machine. Try some new with AES-NI for example. I have years old board, where VIA padlock crypto hw acceleration outperforms sw as well - with 512bytes block size. Milan