The outline of the algorithm for AES CBC encryption requests issketched below:

Any driver requesting the crypto service will place an async cryptorequest on the workqueue. The multi-buffer crypto daemon will pull anAES CBC encryption request from work queue and put each request in anempty data lane for multi-buffer crypto computation. When all the emptylanes are filled, computation will commence on the jobs in parallel andthe job with the shortest remaining buffer will get completed and bereturned. To prevent prolonged stall, when no new jobs arrive, we willflush workqueue of jobs after a maximum allowable delay has elapsed.

To accommodate the fragmented nature of scatter-gather, we will keepsubmitting the next scatter-buffer fragment for a job for multi-buffercomputation until a job is completed and no more buffer fragmentsremain.At that time we will pull a new job to fill the now empty data slot.We check with the multibuffer scheduler to see if there are othercompleted jobs to prevent extraneous delay in returning any completedjobs.

This multi-buffer algorithm should be used for cases where we get atleast 8 streams of crypto jobs submitted at a reasonably high rate.For low crypto job submission rate and low number of data streams, thisalgorithm will not be beneficial. The reason is at low rate, we do notfill out the data lanes before flushing the jobs instead of processingthem with all the data lanes full. We will miss the benefit of parallelcomputation, and adding delay to the processing of the crypto job at thesame time. Some tuning of the maximum latency parameter may be neededto get the best performance.