Re: Asynchronous crypto layer.

[Eugene Surovegin <ebs@ebshome.net>]

On Sun, Oct 31, 2004 at 01:17:19AM +0400, Evgeniy Polyakov wrote:
> On Sat, 30 Oct 2004 13:39:06 -0700
> Eugene Surovegin <ebs@ebshome.net> wrote:
> 
> > On Fri, Oct 29, 2004 at 07:27:41PM +0400, Evgeniy Polyakov wrote:
> > > but it was designed to be usefull only in custom MX box, 
> > 
> > This is not true. I coded it using Hifn PCI card plugged in 440GP eval 
> > board as well in P4 2.6 GHz box.
> > 
> > Driver isn't perfect, it's quite simple, I suspended all work on it 
> > because without async crypto it doesn't make a lot of sense.
> > 
> > > so it has some design notes that I do not agree with.
> > 
> > And they are (I know there are problems, just curious which ones you 
> > "don't agree with") ? 
> 
> It supports only one card, 

Yes, and comment says it trivially fixed  :)

> it has very nontrivial locking, 

locking is really simple, it was obviously done for current sync 
crypto layer.

> which may(I'm not sure after just finished diagonal review) lead to 
> too big latencies,

Huh?
 
> hifn_cipher() can not work with any other crypto design, 

Well, this funny one :). Of course it cannot, because none existed 
when I wrote it. 

If your async stuff will be accepted into the official kernel tree 
I'll re-write it ASAP.

> I doubt it can  work with other card capabilities other then you 
> have implemented without major rewrite.

Hmm, what do you mean "other" card? It's written for particular 
Hifn chip. I wrote it for IPSec acceleration in mind. Some algorithms 
aren't supported (compression for example), because we don't use 
them.

> I'm quite sure it is good driver for current crypto schema, but if
> acrypto will be committed it could not work without complete rewrite.

Yes, that's true :). That's the reason I never officially announced it, 
because current one is quite trivial, and there are a lot of things 
which can be improved upon, after async crypto is in, and IPSec uses 
it.

--
Eugene