Thread (13 messages) 13 messages, 3 authors, 2020-04-03

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

From: Horia Geantă <horia.geanta@nxp.com>
Date: 2020-03-12 11:05:41
Also in: lkml

On 3/12/2020 5:26 AM, Herbert Xu wrote:
On Mon, Mar 09, 2020 at 12:51:32AM +0200, Iuliana Prodan wrote:
quoted

 	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.
In this case, we should not do dev_err.  So you need to be able
to distinguish between the hardware queue being full vs. a real
fatal error on the request (e.g., out-of-memory or some hardware
failure).
Yes, in case of -ENOSPC (HW queue full) the request should be put back
in the SW queue.

Thanks,
Horia
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help