linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Ludvig <michal@logix.cz>
To: Fruhwirth Clemens <clemens@endorphin.org>
Cc: Andrew Morton <akpm@osdl.org>, James Morris <jmorris@redhat.com>,
	cryptoapi@lists.logix.cz, "David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time
Date: Fri, 14 Jan 2005 17:40:39 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.61.0501141709250.17481@maxipes.logix.cz> (raw)
In-Reply-To: <1105712446.18687.33.camel@ghanima>

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

  reply	other threads:[~2005-01-14 16:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Xine.LNX.4.44.0411301009560.11945-100000@thoron.boston.redhat.com>
     [not found] ` <Pine.LNX.4.61.0411301722270.4409@maxipes.logix.cz>
     [not found]   ` <20041130222442.7b0f4f67.davem@davemloft.net>
2005-01-11 17:03     ` PadLock processing multiple blocks at a time Michal Ludvig
2005-01-11 17:08       ` [PATCH 1/2] " Michal Ludvig
2005-01-14 13:10         ` [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers " Michal Ludvig
2005-01-14 14:20           ` Fruhwirth Clemens
2005-01-14 16:40             ` Michal Ludvig [this message]
2005-01-15 12:45               ` Fruhwirth Clemens
2005-01-18 16:49                 ` James Morris
2005-01-20  3:30                   ` David McCullough
2005-01-20 13:47                     ` James Morris
2005-03-03 10:50                       ` David McCullough
2005-01-11 17:08       ` [PATCH 2/2] PadLock processing multiple blocks " Michal Ludvig
2005-01-14  3:05         ` Andrew Morton
2005-01-14 13:15         ` [PATCH 2/2] CryptoAPI: Update PadLock to process multiple blocks at once Michal Ludvig
2005-01-14 22:31 Fw: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time Evgeniy Polyakov
2005-01-14 22:31 ` Evgeniy Polyakov
2005-01-14 22:32 ` Evgeniy Polyakov
2005-01-14 22:33 ` Evgeniy Polyakov
2005-01-14 22:34 ` Evgeniy Polyakov
2005-01-14 22:41 ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0501141709250.17481@maxipes.logix.cz \
    --to=michal@logix.cz \
    --cc=akpm@osdl.org \
    --cc=clemens@endorphin.org \
    --cc=cryptoapi@lists.logix.cz \
    --cc=davem@davemloft.net \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).