Hi Herbert, On 04/28/2014 11:59 AM, Herbert Xu wrote: > On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote: >> >> +#define QCE_MAJOR_VERSION5 0x05 >> +#define QCE_QUEUE_LENGTH 50 > > What is the purpose of this software queue? Why can't you directly > feed the requests to the hardware? > > If the hardware can't handle more than 50 requests in-flight, > then your software queue has failed to handle this since you're > taking requests off the queue before you touch the hardware so > you're not really limiting it to 50. That is, for users that > can wait you're potentially dropping their requests instead > of letting them wait through the backlog mechanism. My assumption was that crypto_ablkcipher_encrypt/decrypt couldn't sleep and I should take the request almost immediately and return the appropriate error value - EINPROGRESS if the hardware is idle and EBUSY if the hardware working on some previous request. Thus if the returned error is EBUSY and the request could be backlogged I should call backlog->complete() when this request is taken actually for processing. What I've done in practice is another story. Is that assumption correct? If so, is crypto_enqueue|dequeue_request() are the proper tools to implement this behaviour? regards, Stan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
