On Tue, 22 Dec 2020, 10:20 David Laight, <David.Laight@aculab.com> wrote:

> From: Song Bao Hua
> > Sent: 21 December 2020 23:02
> ...
> > > For decompression, I would like as low latency as possible which I
> > > think is only possible by doing decompression on a cpu synchronously.
> >
> > One possibility is that we change HW accelerator driver to be sync
> > polling for decompression. But this still depends on async api as
> > this is the framework nowadays, the difference would be the driver
> > won't really block. crypto_wait_req() will return without actual
> > sleep.
>
> How long does the HW accelerated compress/decompress need to be before
> it is actually worth sleeping the process?
> While the HW version might be faster than the SW one, it may not be
> enough faster to allow for the hardware interrupt and process sleep.
> So it may be worth just spinning (polling the hardware register)
> until the request completes.
>
> If decompress are done that way, but compress left async, then
> the decompress might need to fallback to SW if the HW is busy.
>

This is an option too, of course. However please bear in mind that Kerne
mutexes are hybrid in the sense that there will be normally some spinning
first.

~Vitaly


>         David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>