----- Ursprüngliche Mail -----
> Right now we're evaluating two options:
> -reworking v5 above
> -using crypto engine (crypto/crypto_engine.c)
>
> Ideally crypto engine should be the way to go.
> However we need to make sure performance degradation is negligible,
> which unfortunately is not case.
>
> Currently it seems that crypto engine has an issue with sending
> multiple crypto requests from (SW) engine queue -> (HW) caam queue.
>
> More exactly, crypto_pump_requests() performs this check:
> /* Make sure we are not already running a request */
> if (engine->cur_req)
> goto out;
>
> thus it's not possible to add more crypto requests to the caam queue
> until HW finishes the work on the current crypto request and
> calls crypto_finalize_request():
> if (finalize_cur_req) {
> [...]
> engine->cur_req = NULL;
Did you consider using a hybrid approach?
Please let me sketch my idea:
- Let's have a worker thread which serves a software queue.
- The software queue is a linked list of requests.
- Upon job submission the driver checks whether the software queue is empty.
- If the software queue is empty the regular submission continues.
- Is the hardware queue full at this point, the request is put on the software
queue and we return EBUSY.
- If upon job submission the software queue not empty, the new job is also put
on the software queue.
- The worker thread is woken up every time a new job is put on the software
queue and every time CAAM processed a job.
That way we can keep the fast path fast. If hardware queue not full, software queue
can be bypassed completely.
If the software queue is used once it will become empty as soon jobs are getting
submitted at a slower rate and the fast path will be used again.
What do you think?
Thanks,
//richard
