On Thu, Jan 22, 2009 at 03:15:58PM +0800, Huang Ying wrote:
>
> Yes. Except that, now we do not need a spin lock really. I think the
> spin lock may be useful if we enqueue a request on other CPU's queue to
> do load balance. And if it is possible that the work_struct to be
> executed on CPU other
On Thu, 2009-01-22 at 11:04 +0800, Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 10:32:17AM +0800, Huang Ying wrote:
> >
> > This is the first attempt to use a dedicate workqueue for crypto. It is
> > not intended to be merged. Please feedback your comments, especially on
> > desgin.
>
> Thanks for
On Thu, Jan 22, 2009 at 10:32:17AM +0800, Huang Ying wrote:
>
> This is the first attempt to use a dedicate workqueue for crypto. It is
> not intended to be merged. Please feedback your comments, especially on
> desgin.
Thanks for the patch!
> + spin_lock_init(&cpu_queue->lock);
Sinc
On Fri, 2009-01-16 at 11:31 +0800, Herbert Xu wrote:
> On Fri, Jan 16, 2009 at 11:10:36AM +0800, Huang Ying wrote:
> >
> > The scalability of current cryptd implementation is not good. So a
> > per-CPU cryptd kthread implementation is necessary. The per-CPU kthread
> > pool implementation need to
On Wed, Jan 21, 2009 at 04:41:01PM -0500, Jarod Wilson wrote:
> Its a valid use case to have null associated data in a ccm vector, but
> this case isn't being handled properly right now.
>
> The following ccm decryption/verification test vector, using the
> rfc4309 implementation regularly trigger
Its a valid use case to have null associated data in a ccm vector, but
this case isn't being handled properly right now.
The following ccm decryption/verification test vector, using the
rfc4309 implementation regularly triggers a panic, as will any
other vector with null assoc data:
* key: ab2f8a
