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@xxxxxxxxxxx> 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
|