Received-SPF: pass (google.com: domain of linux-crypto+bounces-1294-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240103095006.608744-1-21cnbao@gmail.com> <20240103095006.608744-2-21cnbao@gmail.com>
 <CAJD7tkbB2Tni-xo5orxw-uDHzAcKocc7WeV2536LLbE=PC8=QA@mail.gmail.com>
In-Reply-To: <CAJD7tkbB2Tni-xo5orxw-uDHzAcKocc7WeV2536LLbE=PC8=QA@mail.gmail.com>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 9 Jan 2024 11:38:46 +0800
Message-ID: <CAGsJ_4yk=yrpBWvYukoDbq8288yqLLyox4ozg82GiUyaU+ntWQ@mail.gmail.com>
Subject: Re: [PATCH 1/3] crypto: introduce acomp_is_async to expose if a acomp
 has a scomp backend
To: Yosry Ahmed <yosryahmed@google.com>, herbert@gondor.apana.org.au
Cc: davem@davemloft.net, akpm@linux-foundation.org, ddstreet@ieee.org, 
	sjenning@redhat.com, vitaly.wool@konsulko.com, linux-crypto@vger.kernel.org, 
	chriscli@google.com, chrisl@kernel.org, hannes@cmpxchg.org, 
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, 
	zhouchengming@bytedance.com, Barry Song <v-songbaohua@oppo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 9, 2024 at 6:36=E2=80=AFAM Yosry Ahmed <yosryahmed@google.com> =
wrote:
>
> On Wed, Jan 3, 2024 at 1:50=E2=80=AFAM Barry Song <21cnbao@gmail.com> wro=
te:
> >
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > 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@oppo.com>
> > Tested-by: Chengming Zhou <zhouchengming@bytedance.com>
> > ---
> >  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 =3D=3D &crypto_acomp_type;

Thanks
Barry