Re: [PATCH v4 1/2] crypto: engine - support for parallel requests

On 3/17/2020 5:29 AM, Herbert Xu wrote:

On Thu, Mar 12, 2020 at 12:45:54PM +0000, Iuliana Prodan wrote:

quoted

There are two aspects here:
- if all requests go through crypto-engine, and, in this case, if there
is no space in hw queue, do_one_req returns 0, and actually there will
be no case of do_one_request() < 0;

OK, that makes sense.  However, this way of signaling for more
requests can be racy.  Unless you can guarantee that the driver
is not taking any requests from another engine queue (or any
other source), just because it returned a positive value now does
not mean that it would be able to take a request the next time
you come around the loop.

This case can happen right now, also. I can't guarantee that all drivers 
send all requests via crypto-engine.
This is the second aspect from my other mail. There are cases, when we 
send requests (non crypto API) to hardware without passing to crypto-engine.

To solve this, I'm thinking of adding new patches that doesn't do 
request dequeue from crypto-engine queue, just peek, and dequeues the 
request after was successfully executed by hardware (if it has 
MAY_BACKLOG flag, otherwise will dequeue it). What do you think?

Also, the above modification will imply changes in the drivers that use 
crypto-engine.

Thanks,
Iulia

quoted

I've tried this, but it implies modifications in all drivers. For
example, a driver, in case of error, it frees the resources of the
request. So, will need to map again a request.

I think what we are doing here is a major overhaul to the crypto
engine API so while it's always a good idea to minimise the impact,
we should not let the existing drivers constrain us too much.

Thanks,