On 3/17/2020 5:29 AM, Herbert Xu wrote: > On Thu, Mar 12, 2020 at 12:45:54PM +0000, Iuliana Prodan wrote: >> >> 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 >> 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, >
