On Tue, Jan 9, 2024 at 6:36 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > On Wed, Jan 3, 2024 at 1:50 AM Barry Song <21cnbao@xxxxxxxxx> wrote: > > > > From: Barry Song <v-songbaohua@xxxxxxxx> > > > > Almost all CPU-based compressors/decompressors are actually synchronous > > though they support acomp APIs. While some hardware has hardware-based > > accelerators to offload CPU's work such as hisilicon and intel/qat/, > > their drivers are working in async mode. > > Letting acomp's users know exactly if the acomp is really async will > > help users know if the compression and decompression procedure can > > sleep. > > > > Signed-off-by: Barry Song <v-songbaohua@xxxxxxxx> > > Tested-by: Chengming Zhou <zhouchengming@xxxxxxxxxxxxx> > > --- > > crypto/acompress.c | 8 ++++++++ > > include/crypto/acompress.h | 9 +++++++++ > > 2 files changed, 17 insertions(+) > > > > diff --git a/crypto/acompress.c b/crypto/acompress.c > > index 1c682810a484..99118e879a4a 100644 > > --- a/crypto/acompress.c > > +++ b/crypto/acompress.c > > @@ -152,6 +152,14 @@ struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name, u32 type, > > } > > EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node); > > > > +bool acomp_is_async(struct crypto_acomp *acomp) > > Is synchronous semantically the same as sleepable? IIUC synchronous > code may still sleep, at least generally. The purpose of this change > is to know whether we will sleep or not in the zswap code, so I > suggest the code should be explicit about sleep-ability instead (e.g. > acomp_is_sleepable or acomp_may_sleep). Thanks, Tosry. sounds reasonable. I'd like to ask for Herbert's comment, do we have a better way to know if an acomp can sleep other than checking the below? return tfm->__crt_alg->cra_type == &crypto_acomp_type; Thanks Barry
