On 7/28/2019 11:50 PM, Richard Weinberger wrote:
> ----- 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?
>
Yes, this is on our plate, though we haven't tried it yet.
> 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?
>
The optimization mentioned above - bypassing SW queue (i.e. try enqueuing
to HW queue if SW is empty) should probably be added into crypto engine
implementation itself - for e.g. in crypto_transfer_request().
Thanks,
Horia
