Re: [PATCH 8/9] crypto: qat - expose deflate through acomp api for QAT GEN2

[Giovanni Cabiddu <giovanni.cabiddu@intel.com>]

Hi Herbert,

On Tue, Aug 30, 2022 at 05:08:55PM +0800, Herbert Xu wrote:
> On Fri, Aug 26, 2022 at 03:21:15PM +0100, Giovanni Cabiddu wrote:
> >
> > It would be nice if the user of the api could provide a hint for the
> > size of the destination buffer in acomp_req.dlen.
> 
> The whole point of this is that the user has no idea how big
> the result will be.  If anyone would have a clue, it would be
> whoever is doing the decompression.
> 
> Ideally the hardware would take an SG list, dump whatever result
> that fits into it, and then stop the decompression, dump the
> interim state somewhere so that it can be resumed, ask for memory
> from the driver, and then resume the decompression.
> 
> I understand that hardware already exists that cannot perform
> such an incremental process.  In that case we should hide this
> inadequacy in the driver.
> 
> Here's a suggestion.  Start with whatever value you want (e.g.,
> src * 2), attempt the decompression, if it fails because the
> space is to small, then double it and retry the operation.
I prototyped the solution you proposed and it introduces complexity,
still doesn't fully solve the problem and it is not performant. See
below*.

We propose instead to match the destination buffer size used in scomp
for the NULL pointer use case, i.e. 128KB:
https://elixir.bootlin.com/linux/v6.0-rc5/source/include/crypto/internal/scompress.h#L13
Since the are no users of acomp with this use-case in the kernel, we
believe this will be sufficient.

Can we go with this solution since we have a user waiting for the acomp
implementation in the qat driver?

*Brief description of the prototyped solution:
When the callback detects an overflow condition on a request with a NULL
destination buffer, it schedules a new workqueue. This is since the
callback is running in the context of a tasklet and we want to avoid
atomic allocations.
The workqueue allocates additional pages for the destination buffer, map
those pages, re-construct the FW destination buffer list and re-send the
request to the device, making sure that the request is actually
enqueued.

Regards,

-- 
Giovanni