[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZLsvdS6NbaetDFe1@gondor.apana.org.au>
Date: Sat, 22 Jul 2023 13:23:01 +1200
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Tom Zanussi <tom.zanussi@...ux.intel.com>
Cc: davem@...emloft.net, fenghua.yu@...el.com, vkoul@...nel.org,
dave.jiang@...el.com, tony.luck@...el.com,
wajdi.k.feghali@...el.com, james.guilford@...el.com,
kanchana.p.sridhar@...el.com, vinodh.gopal@...el.com,
giovanni.cabiddu@...el.com, linux-kernel@...r.kernel.org,
linux-crypto@...r.kernel.org, dmaengine@...r.kernel.org
Subject: Re: [PATCH v7 12/14] crypto: iaa - Add support for deflate-iaa
compression algorithm
On Mon, Jul 10, 2023 at 02:06:52PM -0500, Tom Zanussi wrote:
>
> Because the IAA hardware has a 4k history-window limitation, only
> buffers <= 4k, or that have been compressed using a <= 4k history
> window, are technically compliant with the deflate spec, which allows
> for a window of up to 32k. Because of this limitation, the IAA fixed
> mode deflate algorithm is given its own algorithm name, 'deflate-iaa'.
So compressed results produced by this can always be decompressed
by the generic algorithm, right?
If it's only when you decompress that you may encounter failures,
then I suggest that we still use the same algorithm name, but fall
back at run-time if the result cannot be decompressed by the
hardware. Is it possible to fail gracefully and then retry the
decompression in this case?
Thanks,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists