On Tue, Dec 03, 2024 at 12:30:30AM +0000, Sridhar, Kanchana P wrote: > > > Why do we need this "can_batch" field? IIUC, this can be determined > > from the compressor internal fields itself, no? > > > > acomp_has_async_batching(acomp); > > > > Is this just for convenience, or is this actually an expensive thing to compute? > > Thanks for your comments. This is a good question. I tried not to imply that > batching resources have been allocated for the cpu based only on what > acomp_has_async_batching() returns. It is possible that the cpu onlining > code ran into an -ENOMEM error on any particular cpu. In this case, I set > the pool->can_batch to "false", mainly for convenience, so that zswap > can be somewhat insulated from migration. I agree that this may not be > the best solution; and whether or not batching is enabled can be directly > determined just before the call to crypto_acomp_batch_compress() > based on: > > acomp_ctx->nr_reqs == SWAP_CRYPTO_BATCH_SIZE; With ahash request chaining, the idea is to accumulate as much data as you can before you provide it to the Crypto API. The API is responsible for dividing it up if the underlying driver is only able to handle one request at a time. So that would be the ideal model to use for compression as well. Provide as much data as you can and let the API handle the case where the data needs to be divided up. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
