On 4/23/2020 2:47 PM, Herbert Xu wrote: > On Wed, Apr 15, 2020 at 11:26:14PM +0300, Iuliana Prodan wrote: >> Added support for executing multiple requests, in parallel, >> for crypto engine based on a retry mechanism. >> If hardware was unable to execute a backlog request, enqueue it >> back in front of crypto-engine queue, to keep the order >> of requests. >> >> A new variable is added, retry_support (this is to keep the >> backward compatibility of crypto-engine) , which keeps track >> whether the hardware has support for retry mechanism and, >> also, if can run multiple requests. >> >> If do_one_request() returns: >>> = 0: hardware executed the request successfully; >> < 0: this is the old error path. If hardware has support for retry >> mechanism, the request is put back in front of crypto-engine queue. >> For backwards compatibility, if the retry support is not available, >> the crypto-engine will work as before. >> Only MAY_BACKLOG requests are enqueued back into >> crypto-engine's queue, since the others can be dropped. > > This looks a lot nicer! > > However, I do have one little issue with the error case. I think > we should not lump all errors together. For queueing errors, we > should requeue regardless of MAY_BACKLOG. After all, we don't > want to have random packet loss just becayse the queue was full. > > For other errors (e.g., a kmalloc error), we should requeue the > MAY_BACKLOG requests and drop everythin else. > Do you refer to the error codes returned by do_one_request (which sends the req to hw for execution)? If this returns: 1. 0, success; 2. -ENOSPC, I'll requeue it regardless of MAY_BACKLOG; 3. any other error (-EIO, -EINVAL, -ENOMEM, etc), I'll requeue only MAY_BACKLOG requests. Thanks, Iulia
