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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Evgeniy Polyakov <johnpol@xxxxxxxxxxx> wrote:
>
> So, dm-crypt will fail and will not try to process that block again, 
> if crypto returns error. In acrypto I put a queue length as parameter 
> to crypto device (crypto_alg in cryptoapi) structure, and acrypto 
> load balancer always selected device which does have a space in the 
> queue. I think something similar should be created for cryptoapi, so 
> that even if device has higher prio it should not be selected until 
> there is a place in its queue. Software implementation has infinite 
> queue of course. In such case we do not need to have backlog queue,
> which can be overflown too.

The way I've solved is using the MAY_BACKLOG flag.  It's basically
an emergency reserve queue of length 1.  So for each tfm object,
you're guaranteed to be able to queue at least one request which
is sufficient.

This reminds me, I need to refresh my dm-crypt patch and repost it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux