> > ________________________________________ > From: Herbert Xu <[email protected]> > Sent: Tuesday, May 10, 2016 12:46 PM > To: Catalin Vasile > Cc: [email protected]; [email protected]; Horia > Ioan Geanta Neag; Alexandru Porosanu; Scott Wood; Catalin Vasile > Subject: Re: [PATCH] crypto: caam: add backlogging support>
> Catalin Vasile <[email protected]> wrote: > > caam_jr_enqueue() function returns -EBUSY once there are no more slots > > available in the JR, but it doesn't actually save the current request. > > This breaks the functionality of users that expect that even if there is > > no more space for the request, it is at least queued for later > > execution. In other words, all crypto transformations that request > > backlogging (i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such > > an example is dm-crypt. The current patch solves this issue by setting a > > threshold after which caam_jr_enqueue() returns -EBUSY, but since the HW > > job ring isn't actually full, the job is enqueued. > > > > Signed-off-by: Alexandru Porosanu <[email protected]> > > Tested-by: Catalin Vasile <[email protected]>> > This is not acceptable. The request that triggers EBUSY must > be allowed to queue. As the number of tfms is unlimited you > can't just put them onto the hardware queue and hope that it > works out.> Every request will be queued and eventually done. The hardware equipment has a constraint on the number of tfms it can have. Is there a requirement to support an infinite number of tfms on a device? > You should use a software queue instead.> > Cheers, > -- > Email: Herbert Xu <[email protected]> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
