From: Ard Biesheuvel <ardb@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jens Axboe <axboe@kernel.dk>,
Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Kees Cook <keescook@chromium.org>,
qat-linux@intel.com,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Richard Weinberger <richard@nod.at>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
linux-kernel@vger.kernel.org, Eric Biggers <ebiggers@kernel.org>,
Minchan Kim <minchan@kernel.org>, Nick Terrell <terrelln@fb.com>,
linux-block@vger.kernel.org, linux-mtd@lists.infradead.org,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
linuxppc-dev@lists.ozlabs.org, linux-crypto@vger.kernel.org
Subject: Re: [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs
Date: Fri, 28 Jul 2023 11:57:42 +0200 [thread overview]
Message-ID: <CAMj1kXFRAhoyRD8mGe4xKZ-xGord2vwPXHCM7O8DPOpYWcgnJw@mail.gmail.com> (raw)
In-Reply-To: <ZMOQiPadP2jggZ2i@gondor.apana.org.au>
On Fri, 28 Jul 2023 at 11:56, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Jul 18, 2023 at 02:58:26PM +0200, Ard Biesheuvel wrote:
> >
> > Patch #2 removes the support for on-the-fly allocation of destination
> > buffers and scatterlists from the Intel QAT driver. This is never used,
> > and not even implemented by all drivers (the HiSilicon ZIP driver does
> > not support it). The diffstat of this patch makes a good case why the
> > caller should be in charge of allocating the memory, not the driver.
>
> The implementation in qat may not be optimal, but being able to
> allocate memory in the algorithm is a big plus for IPComp at least.
>
> Being able to allocate memory page by page as you decompress
> means that:
>
> 1. We're not affected by memory fragmentation.
> 2. We don't waste memory by always allocating for the worst case.
>
So will IPcomp be able to simply assign those pages to the SKB afterwards?
next prev parent reply other threads:[~2023-07-28 9:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 12:58 [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)" Ard Biesheuvel
2023-07-18 22:32 ` Eric Biggers
2023-07-18 22:54 ` Eric Biggers
2023-07-18 23:06 ` Ard Biesheuvel
2023-07-21 9:10 ` Simon Horman
2023-08-03 9:51 ` Giovanni Cabiddu
2023-08-03 9:59 ` Ard Biesheuvel
2023-08-03 10:29 ` Giovanni Cabiddu
2023-07-18 12:58 ` [RFC PATCH 02/21] crypto: qat - Drop support for allocating destination buffers Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 03/21] crypto: acompress - Drop destination scatterlist allocation feature Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 04/21] net: ipcomp: Migrate to acomp API from deprecated comp API Ard Biesheuvel
2023-07-21 9:11 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 05/21] ubifs: Pass worst-case buffer size to compression routines Ard Biesheuvel
2023-07-18 22:38 ` Eric Biggers
2023-07-19 8:33 ` Ard Biesheuvel
2023-07-19 14:23 ` Zhihao Cheng
2023-07-19 14:38 ` Ard Biesheuvel
2023-07-20 1:23 ` Zhihao Cheng
2023-07-18 12:58 ` [RFC PATCH 06/21] ubifs: Avoid allocating buffer space unnecessarily Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 07/21] ubifs: Migrate to acomp compression API Ard Biesheuvel
2023-07-21 9:19 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 08/21] zram: " Ard Biesheuvel
2023-07-21 9:22 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 09/21] crypto: nx - Migrate to scomp API Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 10/21] crypto: 842 - drop obsolete 'comp' implementation Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 11/21] crypto: deflate " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 12/21] crypto: lz4 " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 13/21] crypto: lz4hc " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 14/21] crypto: lzo-rle " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 15/21] crypto: lzo " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 16/21] crypto: zstd " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 17/21] crypto: cavium/zip " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 18/21] crypto: compress_null " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 19/21] crypto: remove obsolete 'comp' compression API Ard Biesheuvel
2023-07-21 11:07 ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 20/21] crypto: deflate - implement acomp API directly Ard Biesheuvel
2023-07-21 11:12 ` Simon Horman
2023-07-21 11:17 ` Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 21/21] crypto: scompress - Drop the use of per-cpu scratch buffers Ard Biesheuvel
2023-07-28 9:55 ` [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs Herbert Xu
2023-07-28 9:57 ` Ard Biesheuvel [this message]
2023-07-28 9:59 ` Herbert Xu
2023-07-28 10:03 ` Ard Biesheuvel
2023-07-28 10:05 ` Herbert Xu
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=CAMj1kXFRAhoyRD8mGe4xKZ-xGord2vwPXHCM7O8DPOpYWcgnJw@mail.gmail.com \
--to=ardb@kernel.org \
--cc=axboe@kernel.dk \
--cc=dsahern@kernel.org \
--cc=ebiggers@kernel.org \
--cc=edumazet@google.com \
--cc=giovanni.cabiddu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=minchan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qat-linux@intel.com \
--cc=richard@nod.at \
--cc=senozhatsky@chromium.org \
--cc=steffen.klassert@secunet.com \
--cc=terrelln@fb.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;
as well as URLs for NNTP newsgroup(s).