Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261929AbVANQlb (ORCPT ); Fri, 14 Jan 2005 11:41:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261830AbVANQl3 (ORCPT ); Fri, 14 Jan 2005 11:41:29 -0500 Received: from maxipes.logix.cz ([217.11.251.249]:42428 "EHLO maxipes.logix.cz") by vger.kernel.org with ESMTP id S261929AbVANQkt (ORCPT ); Fri, 14 Jan 2005 11:40:49 -0500 Date: Fri, 14 Jan 2005 17:40:39 +0100 (CET) From: Michal Ludvig To: Fruhwirth Clemens Cc: Andrew Morton , James Morris , cryptoapi@lists.logix.cz, "David S. Miller" , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time In-Reply-To: <1105712446.18687.33.camel@ghanima> Message-ID: References: <20041130222442.7b0f4f67.davem@davemloft.net> <1105712446.18687.33.camel@ghanima> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2516 Lines: 54 On Fri, 14 Jan 2005, Fruhwirth Clemens wrote: > On Fri, 2005-01-14 at 14:10 +0100, Michal Ludvig wrote: > > > This patch extends crypto/cipher.c for offloading the whole chaining modes > > to e.g. hardware crypto accelerators. It is much faster to let the > > hardware do all the chaining if it can do so. > > Is there any connection to Evgeniy Polyakov's acrypto work? It appears, > that there are two project for one objective. Would be nice to see both > parties pulling on one string. These projects do not compete at all. Evgeniy's work is a complete replacement for current cryptoapi and brings the asynchronous operations at the first place. My patches are simple and straightforward extensions to current cryptoapi that enable offloading the chaining to hardware where possible. > > + void (*cia_ecb)(void *ctx, u8 *dst, const u8 *src, u8 *iv, > > + size_t nbytes, int encdec, int inplace); > > + void (*cia_cbc)(void *ctx, u8 *dst, const u8 *src, u8 *iv, > > + size_t nbytes, int encdec, int inplace); > > + void (*cia_cfb)(void *ctx, u8 *dst, const u8 *src, u8 *iv, > > + size_t nbytes, int encdec, int inplace); > > + void (*cia_ofb)(void *ctx, u8 *dst, const u8 *src, u8 *iv, > > + size_t nbytes, int encdec, int inplace); > > + void (*cia_ctr)(void *ctx, u8 *dst, const u8 *src, u8 *iv, > > + size_t nbytes, int encdec, int inplace); > > What's the use of adding mode specific functions to the tfm struct? And > why do they all have the same function type? For instance, the "iv" or > "inplace" argument is meaningless for ECB. The prototypes must be the same in my implementation, because in crypt() only a pointer to the appropriate mode function is taken and further used as "(func*)(arg, arg, ...)". BTW these functions are not added to "struct crypto_tfm", but to "struct crypto_alg" which describes what a particular module supports (i.e. along with the block size, algorithm name, etc). In this case it can say that e.g. padlock.ko supports encryption in CBC mode in addition to a common single-block processing. BTW I'll look at the pointers of the tweakable api over the weekend... Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal - 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/