On Thu, 2009-01-22 at 15:30 +0800, Herbert Xu wrote: > On Thu, Jan 22, 2009 at 03:15:58PM +0800, Huang Ying wrote: The only needed spin lock usage is cryptd_tfm_in_queue() now, I think we can protect that via RCU, what's your opinions? > > 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 original CPU for CPU hotplug (current code do > > not). > > Right, but I think load-balancing should be explicitly enabled, > i.e., we probably don't want to do it by default for AES-NI. > > The way I see load balancing work is if you had a template that > sat on top of cryptd pass the requests to the cryptd on a CPU > it chooses. But I think the simplest method to pass requests to specified CPU is via work queue (queue_work_on()). We can add a function named cryptd_enqueue_request_on(), and construct a load-balance version cryptd on top of that. > Then we can enable it for any algorithm in the system simply > by instantiating that template for it. Well. At least we can just remove spin lock now, and if it is necessary we can add that back without big effort. Best Regards, Huang Ying
Attachment:
signature.asc
Description: This is a digitally signed message part
