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
