On Thu, Mar 12, 2020 at 01:05:32PM +0200, Horia Geantă wrote: > On 3/12/2020 5:26 AM, Herbert Xu wrote: > > On Mon, Mar 09, 2020 at 12:51:32AM +0200, Iuliana Prodan wrote: > >> > >> ret = enginectx->op.do_one_request(engine, async_req); > >> - if (ret) { > >> - dev_err(engine->dev, "Failed to do one request from queue: %d\n", ret); > >> - goto req_err; > >> + can_enq_more = ret; > >> + if (can_enq_more < 0) { > >> + dev_err(engine->dev, "Failed to do one request from queue: %d\n", > >> + ret); > >> + goto req_err_1; > >> + } > > > > So this now includes the case of the hardware queue being full > > and the request needs to be queued until space opens up again. > I see no difference when compared with existing implementation: > in both cases failing the transfer from SW queue to HW queue means > losing the request irrespective of the error code returned by .do_one_request. > > This doesn't mean it shouldn't be fixed. I don't think they are the same though. With the existing code, you only ever have one outstanding request so a new one is only given over to the hardware after the previous one has completed. That means that the only errors you expect to get from the driver are fatal ones that you cannot recover from. With parallel requests, you will be giving as many requests to the driver as it can take. In fact the error condition is now used to tell the engine to stop giving more requests. This is in no way the same as a fatal error from before. We should not print out an error in this case and we should ensure that the request is put back on the queue and reprocessed when the driver comes back for more. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt