On Fri, 2014-05-30 at 17:26 +0800, Herbert Xu wrote: > On Fri, May 23, 2014 at 04:02:12PM -0700, Tim Chen wrote: > > > > The outline of the algorithm is sketched below: > > Any driver requesting the crypto service will place an async > > crypto request on the workqueue. The multi-buffer crypto daemon will > > pull request from work queue and put each request in an empty data lane > > for multi-buffer crypto computation. When all the empty lanes are filled, > > computation will commence on the jobs in parallel and the job with the > > shortest remaining buffer will get completed and be returned. To prevent > > prolonged stall when there is no new jobs arriving, we will flush a crypto > > job if it has not been completed after a maximum allowable delay. > > I'm a bit uncomfortable with the idea of only having a delay here. > How about in addition to the delay we also flush the queue as > soon as the CPU is idle? It's a good idea to get the jobs processed with flush when there are cpu cycles nobody else is using. I'll have to think a bit of what mechanism to use to implement this. Any suggestions will be welcomed. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
