[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMOTAB595JyptIN4@gondor.apana.org.au>
Date: Fri, 28 Jul 2023 18:05:52 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: linux-crypto@...r.kernel.org, Eric Biggers <ebiggers@...nel.org>,
Kees Cook <keescook@...omium.org>, Haren Myneni <haren@...ibm.com>,
Nick Terrell <terrelln@...com>, Minchan Kim <minchan@...nel.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Jens Axboe <axboe@...nel.dk>,
Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
Richard Weinberger <richard@....at>,
David Ahern <dsahern@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
qat-linux@...el.com, linuxppc-dev@...ts.ozlabs.org,
linux-mtd@...ts.infradead.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 00/21] crypto: consolidate and clean up compression
APIs
On Fri, Jul 28, 2023 at 12:03:23PM +0200, Ard Biesheuvel wrote:
>
> Fair enough. But my point remains: this requires a lot of boilerplate
> on the part of the driver, and it would be better if we could do this
> in the acomp generic layer.
Absolutely. If the hardware can't support allocate-as-you-go then
this should very much go into the generic layer.
> Does the IPcomp case always know the decompressed size upfront?
No it doesn't know. Of course, we could optimise it because we know
that in 99% cases, the packet is going to be less than 4K. But we
need a safety-net for those weird jumbo packets.
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