On Tue, Aug 23, 2005 at 01:02:09PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> On Tue, 23 Aug 2005 20:12:12 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Aug 23, 2005 at 06:40:42PM +0300, Ronen Shitrit ([EMAIL PROTECTED])
> > wrote:
> > > Hi
> > >
> > > The device I'm planning to use can support synchronous encryption, but
> > > Isn't any device can do it, by polling the device till it complete?
> > > Won't it be a waste of time, waiting for the HW accelerator to complete
> > > processing,
> > > While other tasks can use the CPU?
> >
> > Sure.
> > I mean VIA/Freescale like processing - it does not support asynchronous
> > processing, but instead doing crypto operations like original CPU
> > instructions.
> >
> fyi, Freescale's SEC crypto engine is asynchronous to the core, i.e. the core
> CPU is free during crypto processing.
>
> Currently, I see no point in porting the existing tfm crypto api to a
> freescale device, except perhaps in preparation/anticipation for Herbert's
> async mods. If you're porting to a Freescale device for use with IPSec,
> you'd want an API to provide single-pass, e.g. encrypt-and-hash operations,
> which the Freescale device supports natively. I believe OCF supports this.
Yes, you are right, I thought ColdFire's SEC is synchronous
in respect to input dataflow.
So, currently only VIA ACE xcrypt is fully synchronous and
can be (and it is) supported under existing TFM stack.
I agree theres is no need to port existing asynchronous crypto drivers
like freescale, HIFN, IXP and others to TFM stack.
> Kim
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
