From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ard Biesheuvel <ardb@kernel.org>,
David Howells <dhowells@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Roberto Sassu <roberto.sassu@huaweicloud.com>,
Stefan Berger <stefanb@linux.ibm.com>,
Mimi Zohar <zohar@linux.ibm.com>,
dmitry.kasatkin@gmail.com, Jarkko Sakkinen <jarkko@kernel.org>,
keyrings@vger.kernel.org,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [v2 PATCH 0/5] crypto: Add akcipher interface without SGs
Date: Tue, 27 Jun 2023 23:21:20 -0700 [thread overview]
Message-ID: <20230628062120.GA7546@sol.localdomain> (raw)
In-Reply-To: <ZJlk2GkN8rp093q9@gondor.apana.org.au>
On Mon, Jun 26, 2023 at 06:13:44PM +0800, Herbert Xu wrote:
> On Mon, Jun 26, 2023 at 12:03:04PM +0200, Ard Biesheuvel wrote:
> >
> > In any case, what I would like to see addressed is the horrid scomp to
> > acomp layer that ties up megabytes of memory in scratch space, just to
> > emulate the acomp interface on top of scomp drivers, while no code
> > exists that makes use of the async nature. Do you have an idea on how
> > we might address this particular issue?
>
> The whole reason why need to allocate megabytes of memory is because
> of the lack of SG lists in the underlying algorithm. If they
> actually used SG lists and allocated pages as they went during
> decompression, then we wouldn't need to pre-allocate any memory
> at all.
I don't think that is a realistic expectation. Decompressors generally need a
contiguous buffer for decompressed data anyway, up to a certain size which is
32KB for DEFLATE but can be much larger for the more modern algorithms. This is
because they decode "matches" that refer to previously decompressed data by
offset, and it has to be possible to index the data efficiently.
(Some decompressors, e.g. zlib, provide "streaming" APIs where you can read
arbitrary amounts. But that works by actually decompressing into an internal
buffer that has sufficient size, then copying to the user provided buffer.)
The same applies to compressors too, with regards to the original data.
I think the "input/output is a list of pages" model just fundamentally does not
work well for software compression and decompression. To support it, either
large temporary buffers are needed (they might be hidden inside the
(de)compressor, but they are there), or vmap() or vm_map_ram() is needed.
FWIW, f2fs compression uses vm_map_ram() and skips the crypto API entirely...
If acomp has to be kept for the hardware support, then maybe its scomp backend
should use vm_map_ram() instead of scratch buffers?
- Eric
next prev parent reply other threads:[~2023-06-28 9:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 9:35 [PATCH 0/5] crypto: Add akcipher interface without SGs Herbert Xu
2023-06-13 9:38 ` [PATCH 1/5] crypto: akcipher - Add sync interface without SG lists Herbert Xu
2023-06-13 9:38 ` [PATCH 2/5] crypto: dsa - Add interface for sign/verify Herbert Xu
2023-06-13 9:38 ` [PATCH 3/5] KEYS: Add forward declaration in asymmetric-parser.h Herbert Xu
2023-06-13 9:38 ` [PATCH 4/5] KEYS: asymmetric: Move sm2 code into x509_public_key Herbert Xu
2023-06-13 12:50 ` David Howells
2023-06-14 10:12 ` Herbert Xu
2023-06-13 9:38 ` [PATCH 5/5] KEYS: asymmetric: Use new crypto interface without scatterlists Herbert Xu
2023-06-13 12:53 ` [PATCH 0/5] crypto: Add akcipher interface without SGs David Howells
2023-06-14 10:10 ` Herbert Xu
2023-06-15 10:26 ` [v2 PATCH " Herbert Xu
2023-06-15 10:28 ` [PATCH 1/5] crypto: akcipher - Add sync interface without SG lists Herbert Xu
2023-06-15 10:28 ` [PATCH 2/5] crypto: sig - Add interface for sign/verify Herbert Xu
2023-06-15 10:28 ` [PATCH 3/5] KEYS: Add forward declaration in asymmetric-parser.h Herbert Xu
2023-06-15 10:28 ` [PATCH 4/5] KEYS: asymmetric: Move sm2 code into x509_public_key Herbert Xu
2023-06-15 10:28 ` [PATCH 5/5] KEYS: asymmetric: Use new crypto interface without scatterlists Herbert Xu
2023-06-26 9:21 ` [v2 PATCH 0/5] crypto: Add akcipher interface without SGs Ard Biesheuvel
2023-06-26 9:52 ` Herbert Xu
2023-06-26 10:03 ` Ard Biesheuvel
2023-06-26 10:13 ` Herbert Xu
2023-06-28 6:21 ` Eric Biggers [this message]
2023-06-28 16:58 ` Ard Biesheuvel
2023-06-28 17:33 ` Eric Biggers
2023-06-28 17:44 ` Ard Biesheuvel
2023-06-28 17:55 ` Linus Torvalds
2023-06-28 18:34 ` David Howells
2023-06-28 20:10 ` Linus Torvalds
2023-06-29 4:49 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230628062120.GA7546@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=roberto.sassu@huaweicloud.com \
--cc=stefanb@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox