On Fri, May 25, 2007 at 11:35:32AM +0200, Sebastian Siewior (linux-crypto@xxxxxxxxxxxxxxxx) 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
