Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753089AbdCBOHz (ORCPT ); Thu, 2 Mar 2017 09:07:55 -0500 Received: from mail-io0-f174.google.com ([209.85.223.174]:33175 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750915AbdCBOHx (ORCPT ); Thu, 2 Mar 2017 09:07:53 -0500 MIME-Version: 1.0 X-Originating-IP: [217.140.96.140] In-Reply-To: References: <1486463731-6224-1-git-send-email-binoy.jayan@linaro.org> <68f70534-a309-46ba-a84d-8acc1e6620e5@gmail.com> From: Gilad Ben-Yossef Date: Thu, 2 Mar 2017 16:01:03 +0200 Message-ID: Subject: Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt To: Ondrej Mosnacek Cc: Milan Broz , Binoy Jayan , Oded , Ofir , Herbert Xu , "David S. Miller" , linux-crypto@vger.kernel.org, Mark Brown , Arnd Bergmann , Linux kernel mailing list , Alasdair Kergon , Mike Snitzer , dm-devel@redhat.com, Shaohua Li , linux-raid@vger.kernel.org, Rajendra 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: 2081 Lines: 50 On Wed, Mar 1, 2017 at 3:21 PM, Ondrej Mosnacek wrote: > 2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef : > > Wouldn't adopting a bulk request API (something like what I tried to > do here [1]) that allows users to supply multiple messages, each with > their own IV, fulfill this purpose? That way, we wouldn't need to > introduce any new modes into Crypto API and the drivers/accelerators > would only need to provide bulk implementations of common modes > (xts(aes), cbc(aes), ...) to provide better performance for dm-crypt > (and possibly other users, too). > > I'm not sure how exactly these crypto accelerators work, but wouldn't > it help if the drivers simply get more messages (in our case sectors) > in a single call? I wonder, would (efficiently) supporting such a > scheme require changes in the HW itself or could it be achieved just > by modifying driver code (let's say specifically for your CryptoCell > accelerator)? > > [1] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23007.html > >From a general perspective - that is things are expect to be true not just for CryptoCell but for most HW crypto engines, you want two things - for the HW engine to be able to burst work for a long time and than rest for a long time vs. a stop and go scheme (engine utilization) and for the average IO transaction to be relatively long (bus utilization) So, a big cluster size i.e. Milan's proposal) works great - you get both. Submitting a series of sequential small clusters where the HW can calculate the IV (e.g. Binoy's proposal) works great if the HW supports it - you get both. A batched series of small clusters + IV is less favorable - if your HW engines has lots of parallel context processing (this is expensive for HW) you might enjoy engine utilization but the bus utilization will be low - lots of small transactions. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru