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

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

On Fri, May 25, 2007 at 11:35:32AM +0200, Sebastian Siewior (linux-crypto@ml.breakpoint.cc) 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