Re: [1/1 take 2] HIFN: preliminary HIFN 795x driver for new async cryptoapi.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Fri, Jun 22, 2007 at 02:29:48PM +0200, Sebastian Siewior (linux-crypto@ml.breakpoint.cc) wrote:
> * Evgeniy Polyakov | 2007-06-22 15:57:26 [+0400]:
> 
> >On Fri, Jun 22, 2007 at 03:28:44PM +0800, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> >> > +	 * Actually I need to think about how to handle the case, when queue is full.
> >> > +	 * So far error (-EINVAL) is returned.
> >> > +	 */
> >> 
> >> OK you need to provide a software queue here.  Since you already
> >> have a hardware queue, you may choose to have a queue with a
> >> (advisory) maximum length of zero.  However, a queue is still
> >> necessary since requests with the MAY_BACKLOG flag must never
> >> be discarded.
> >> 
> >> This is (or will be) used by users such as dm-crypt that must be
> >> able to add at least one request but can throttle themselves
> >> afterwards .
> >
> >What will prevent crypto user from filling that queue with crypto
> >requests more and more when hardware is not capable to work with such
> >rate?
> 
> Nothing, the hw signalizes with -EBUSY such a state and the crypto user
> has to slow down.
> If the crypto user continues such a behavior, the system will go OOM
> (this is atleast my understanding).

That is what is returned right now - -EBUSY if queue is full and -EINVAL
if there are some more serious errors, but there is no way dm-crypt will
recover from error.

-- 
	Evgeniy Polyakov