[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z2_lAGctG0DDSCIH@gondor.apana.org.au>
Date: Sat, 28 Dec 2024 19:46:08 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Kanchana P Sridhar <kanchana.p.sridhar@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, hannes@...xchg.org,
yosryahmed@...gle.com, nphamcs@...il.com, chengming.zhou@...ux.dev,
usamaarif642@...il.com, ryan.roberts@....com, 21cnbao@...il.com,
akpm@...ux-foundation.org, linux-crypto@...r.kernel.org,
davem@...emloft.net, clabbe@...libre.com, ardb@...nel.org,
ebiggers@...gle.com, surenb@...gle.com, kristen.c.accardi@...el.com,
wajdi.k.feghali@...el.com, vinodh.gopal@...el.com
Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for
compress/decompress batching.
On Fri, Dec 20, 2024 at 10:31:09PM -0800, Kanchana P Sridhar wrote:
> This commit adds get_batch_size(), batch_compress() and batch_decompress()
> interfaces to:
First of all we don't need a batch compress/decompress interface
because the whole point of request chaining is to supply the data
in batches.
I'm also against having a get_batch_size because the user should
be supplying as much data as they're comfortable with. In other
words if the user is happy to give us 8 requests for iaa then it
should be happy to give us 8 requests for every implementation.
The request chaining interface should be such that processing
8 requests is always better than doing 1 request at a time as
the cost is amortised.
Cheers,
--
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