Hi Herbert, > -----Original Message----- > From: linux-crypto-owner@xxxxxxxxxxxxxxx [mailto:linux-crypto- > owner@xxxxxxxxxxxxxxx] On Behalf Of Herbert Xu > Sent: Friday, September 18, 2015 5:11 PM > To: Porosanu Alexandru-B06830 <alexandru.porosanu@xxxxxxxxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx; Geanta Neag Horia Ioan-B05471 > <Horia.Geanta@xxxxxxxxxxxxx>; Pop Mircea-R19439 > <mircea.pop@xxxxxxxxxxxxx> > Subject: Re: [PATCH v2] crypto/caam: add backlogging support > > On Fri, Sep 18, 2015 at 02:07:38PM +0000, Porosanu Alexandru wrote: > > > > MAY_BACKLOG requests will fail once you run out of memory (f.i. > > backlogging using crypto_queue) Now, for this patch requests will be > dropped if there are no more "backlogging" slots available. > > Would limiting the # of tfms w/MAY_BACKLOG associated with the driver > to the # of backlogging slots be OK? > > Sure running out of memory is obviously a good reason to fail a request. But > if you still have memory MAY_BACKLOG must not fail. Well, the HW has less than the whole RAM for backlogging requests, it has the # of available backlogging requests slots. Then it will start dropping, just like in the out-of-mem case. > > Each tfm must be able to submit at least one MAY_BACKLOG request, that's > the whole point of this flag. It's used for disk encryption where failing is not > an option. But dm-crypt is behaving properly: once -EBUSY is returned, it will sleep. And CAAM will wake it up once it has processed the backlog request. dm-crypt was the driving factor for fixing this long-standing issue.... > > Cheers, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html Thanks, Alex P. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
