linux-kernel - Re: Backlog support for CAAM?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <VI1PR0402MB348585019425D0D9FC9177A798DC0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
Date:   Tue, 30 Jul 2019 10:28:14 +0000
From:   Horia Geanta <horia.geanta@....com>
To:     Richard Weinberger <richard@....at>
CC:     Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Aymen Sghaier <aymen.sghaier@....com>,
        david <david@...ma-star.at>, Baolin Wang <baolin.wang@...aro.org>
Subject: Re: Backlog support for CAAM?

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