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

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

On Fri, Aug 26, 2022 at 06:28:48PM +0800, Herbert Xu wrote:
> On Thu, Aug 18, 2022 at 07:01:19PM +0100, Giovanni Cabiddu wrote:
> >
> > +	/* Handle acomp requests that require the allocation of a destination
> > +	 * buffer. The size of the destination buffer is double the source
> > +	 * buffer to fit the decompressed output or an expansion on the
> > +	 * data for compression.
> > +	 */
> > +	if (!areq->dst) {
> > +		dlen = 2 * slen;
> > +		areq->dst = sgl_alloc(dlen, f, NULL);
> > +		if (!areq->dst)
> > +			return -ENOMEM;
> > +	}
> 
> So what happens if the decompressed result is more than twice as
> long as the source?
The QAT HW will report that the destination buffer is not sufficiently
large to store the decompressed result and the job will fail with an
error and with dlen=0.

From the use case described in this thread [1], an option would be to
allocate always 64KB, i.e. IPCOMP_SCRATCH_SIZE [2].
Alternatively, allocate twice the source rounded up to 64KB:

#define MIN_DST_BUFFER_SZ 65536
    if (!areq->dst) {
        dlen = 2 * slen;
	dlen = dlen < MIN_DST_BUFFER_SZ ? MIN_DST_BUFFER_SZ : dlen;
	...
    }

What do you think?

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.

Regards,

-- 
Giovanni

[1] https://lore.kernel.org/all/20160923150518.GA20384@gondor.apana.org.au/
[2] https://elixir.bootlin.com/linux/latest/source/include/net/ipcomp.h#L7