On Fri, May 25, 2007 at 11:35:32AM +0200, Sebastian Siewior ([EMAIL PROTECTED])
wrote:
> * Evgeniy Polyakov | 2007-05-25 12:55:10 [+0400]:
>
> >Well, it is just hardware queue increase, so essentially for correct
> >work it should return -EBUSY in case driver does not accept requests
> >anymore (no matter if they are pushed into hardware or linked into
> >backlog queue). According to sleeping with CRYPTO_TFM_REQ_MAY_BACKLOG -
> >what about ipsec, where it is not allowed to sleep?
>
> Can't you the drop packet than and hope further packets will arrive
> slowly or is the packet allready ACKed and you are not allowed to lose
> it?
It is quite normal to lose packets in network stack - NIC's queue is
limited too and hardware can drop packets whatever it likes.
TCP will just retransmit the packet, and no one cares about UDP.
In case of dm-crypt situation is different - first, it sets may-sleep
flag, which basically means that it can not fail. But if it fails, block
io request is completed with -EIO error.
Essentially this will be dropped down to bio_end_io, which does not get
into account error, but checks if bio is uptodate, appropriate bit is
not set when bio is completed with error.
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.
> Sebastian
--
Evgeniy Polyakov
-
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
