From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FDC0C48BC3 for ; Tue, 20 Feb 2024 05:05:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD7B56B0082; Tue, 20 Feb 2024 00:05:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A89666B0083; Tue, 20 Feb 2024 00:05:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94F9C6B0088; Tue, 20 Feb 2024 00:05:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 85AF46B0082 for ; Tue, 20 Feb 2024 00:05:31 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 47FCCA0333 for ; Tue, 20 Feb 2024 05:05:31 +0000 (UTC) X-FDA: 81810994062.01.8E664CE Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by imf23.hostedemail.com (Postfix) with ESMTP id 71A6414000A for ; Tue, 20 Feb 2024 05:05:29 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EUgRCnny; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708405529; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rk8k0QjoPMjzPDhGJ3Q3tVXGO0o6Fb9cJe6VdL7s/5k=; b=qsH9W7KWJES734CenKjjNEc8cBfg4EpYcgrO86PeqE2RemeY5UVhgl625BULI4pVwjaS7r YRkmM5KaK/kyfOKkGzslzag06Y5DQAelhTnTAwCb56orD93TNzKt6eWiZsoEMErlbpJ3ot Lo4QQN8QEAPNZlbNt32beLPPDiz6knM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708405529; a=rsa-sha256; cv=none; b=hA4kvxlmHYVCBGZDK5ZCYVR3wasxutMqbkr9D9Ey6nJKBVZoLjAxvbZtbyLpyN6pcDtE+z Wwxz23etFoNErlUdaTxzYoJX6OIv5YLYeuDI0E2lDNJNbZVOiYfX1Mu5FwGX9jugb66J6w ZQH16JlHNyNXuWtLgIkzFr3xXJMMSFQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EUgRCnny; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-7d2e15193bbso2946741241.0 for ; Mon, 19 Feb 2024 21:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708405528; x=1709010328; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rk8k0QjoPMjzPDhGJ3Q3tVXGO0o6Fb9cJe6VdL7s/5k=; b=EUgRCnnywiLvIpna6MnNDY6YyIvIrGVUzNmWhqPdtQDd/Gm0loe2w1Gb6vqm9RKOY+ /sNnHetxEt7dVe/zSI3zPWl6VUSkp9CDJoK3J6MKgyxVrk7s2XPNHxFH/Hn2c5f9oDQt ef7hZuTbXxrlT9v3qfPvHrVyJsWYzSIyFNMmaa2ap3Eje3jdjGmxvWtvSyCfcTWuIt4Y GLzcltxnodOWLsaDIPeiz9u+os094a2rZeatdnXQNkyev118Kd1N0RXHrPxCI6PgAi9E rGRma5z9puWzrjyaxTVWDfpvk1mxOYq2SXnuMbCMuvMeNRIweMdRE6bc2oJXFWsyulaj nWvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708405528; x=1709010328; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rk8k0QjoPMjzPDhGJ3Q3tVXGO0o6Fb9cJe6VdL7s/5k=; b=v/k3b4KRhHrWAtjuNmmLHeBpESTVPvSG/KrhSwW4iB7HR/50IZ5VVpRXVCo/IkiHwI YHpRJkp64IQwav6WcQjayc6k6u50BaFJkUxRQzs5G6KohTS97NYtlvzQVtMUHcGMiYBk BWS76f6xGA38D4cE39y1uFahTfnI/P1oOnEA/Ss/RGuGWuS9bxhU2u9GBFGvDW9YK9Ll 231cUQtJz2f4z4/J/UfGjt1w5jX+wFPG7a+zcfc4rmURKIghUcLLkOhm8IhYnq87mkWI T5Ur4/cWqUVV5HG3kwHu/drcR9iM/jF6u1CimX60bt2xSf5otVeM13JwjzmNLhQ7SAeg 0WgQ== X-Forwarded-Encrypted: i=1; AJvYcCU7gqcybSeMnaD8VSJ2lvgdqPEWEmbc6LFKdtWde28hcmHAUM0yJflK4c3bc/3hl0hqWqPz90zQVEgV1diOMjxwSY4= X-Gm-Message-State: AOJu0YzTWWqas7Y/Q23+kvYjGDckiV0eWCiq1jP9meO7VA+oSLdqzwQg UvCxn1gwq6QT94fbkec0Hlyw0RN9JKMWFpVLd0xssC8Jk/zRzvJTCAOt97EChsI56rAZ4+Whj7C m33Xhtes72ZH6JSGEHhkvpgpuHF4= X-Google-Smtp-Source: AGHT+IFTy+laXX+oRg5/omXGQg3uJcAt19c+6WAcGgFfpTneHrbyZH3LUAe8HUBrDAS2gWl1liNEkkgl6pfN4ghdAqc= X-Received: by 2002:a1f:dec1:0:b0:4cb:d4a:3da2 with SMTP id v184-20020a1fdec1000000b004cb0d4a3da2mr4585852vkg.6.1708405528454; Mon, 19 Feb 2024 21:05:28 -0800 (PST) MIME-Version: 1.0 References: <20240220025545.194886-1-21cnbao@gmail.com> <20240220025545.194886-2-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 20 Feb 2024 18:05:16 +1300 Message-ID: Subject: Re: [PATCH v4 1/3] crypto: introduce crypto_acomp_get_alg_flags to expose algorithm flags To: Herbert Xu Cc: akpm@linux-foundation.org, davem@davemloft.net, hannes@cmpxchg.org, linux-crypto@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, yosryahmed@google.com, zhouchengming@bytedance.com, chriscli@google.com, chrisl@kernel.org, ddstreet@ieee.org, linux-kernel@vger.kernel.org, sjenning@redhat.com, vitaly.wool@konsulko.com, Barry Song , Yang Shen , Zhou Wang , Tom Zanussi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 71A6414000A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: wkzawhdzcyoy3t1r3qfthki7k7oxe1nw X-HE-Tag: 1708405529-951800 X-HE-Meta: U2FsdGVkX18tQa9fI3GE28ilddFWZ5gloFtD4dDu+kMri3+Tqi4K1QXcWTfZuhsrsq6ywMRupXzZnNcZOWWpcEqXYkp/lFXLaCytc/ik0x/OGv/9l4Au/NWTHSOJ152798ociNxy6p6E7urJw2F9hxPv69fk/IqTWNXgYB+Xl/heqxC8rtGSkK5MsTywQHEjgj/4stFX8Je1hN7QB0MLidVdiGWrVyrrCnt6ejbyeD71yK1A/tkdsTpJBNBKepKO1TUggtdZG8iMe7MrPzF83wbnVUr2LMnEd5kHaFEGtVQnM/hJqHBeTbpPM25dpa8Ft9t8oCm1RgcBbHMV2HeuYL7uosxew+zxAUytKfIf3ijfra+O/MPVb5BgDz1rVvXsDowmIoMVYTWQQMOtfiD782HbkYlRzANAH29V4QPUgtc5M7RwWfDejxZfj5PaZMTPm4QGo6Rf+G3fUsM2e0mffzx4KtPRG9d6pl2RO/dQF8gt+2rBeaSyTb1DKsCTdzp5lw4S3haz0HnWo2ZSvXKVMtFJMJjxWp1GebJFaVhgOyogiHuRHhy9OtbNhoyxKqDYLfTiLDX56RJGR2fnLwX88nSEwo6M3O1PoKtBjpp7ul4ybCF9MTpjgHA0l8ejDvY/RdOL1lxKaE7cQ4r4vWxn+HbsOoSFgVAH1DHeq35ciak081zalXS7fDUUYqZ2Kss+RvzTRLQjjbIJUEj6KGlWMY1iWkxrRdF07s1Gxj6iF+40NEwZec19B2VqDsLJ/4KJZs91o6xmXcTdvkUtP/hnj+vCUjLJ5as0/tiFJ340nyCoY03lMYqlVe8bSs73oeJ6pRRRpxfcNKF0AYABgQn6HcKV19qoG8B5ToDJXoXghErqKZBJZno74atlEys5oe/7UXJsY2uOHUxG1aO6SzaCnSueYz5N5W41g1iPSzXV9xuZUCuOJ7dMQ9pglFihtHIrThPofVILn6+rPlRXFX+ qAD3jRyV iA/Jh9PWtS0Nmb2cgkKpcyUJxFJl4A3iL8VJnIxrF1ijIDl1eIOdDgiV8fn+jzWB9RYjTldUxkFMkmql5C8bHwU6b7XVfSkeFkT71zt21yMCU+QE60pPwIoZFt3MEeUI5Clqt3J6qtE7fWB5hPA+a9RI+5b+FBLJLudlB64yVz+LVAowgvnXWNKLz2egrOyQ0FOsed4daiHkh/v7F4yj1Buk6HPrOK+Dz1eNN27I0Sa2dRIIYVnV1bzDC2tL/4CfoE2pb1+grOGRBY1X6ReOgfIlW0F2onH/csTcWapSR+iu5tc5YwW1iqp8fQgqY58kUKE0SocHZDrDN5PoKzDCRecWC2Lcf9s+y6HsltnrVdZNz7hdfxPKsLGkgeqfLe/ARWWPhwlV0ZmlagEbPf17mPxIJXQMO66/zScv++IQ6rex3ANbOtHB1ynpoK1iDHsV3GllBnovtv6m1sQqw0fJRL+Ih41G0Tx95QbTW98Ame6yremU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 20, 2024 at 5:14=E2=80=AFPM Herbert Xu wrote: > > On Tue, Feb 20, 2024 at 03:55:43PM +1300, Barry Song wrote: > > > > diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c b/drivers/crypto= /hisilicon/zip/zip_crypto.c > > index c650c741a18d..94e2d66b04b6 100644 > > --- a/drivers/crypto/hisilicon/zip/zip_crypto.c > > +++ b/drivers/crypto/hisilicon/zip/zip_crypto.c > > @@ -591,6 +591,7 @@ static struct acomp_alg hisi_zip_acomp_deflate =3D = { > > .base =3D { > > .cra_name =3D "deflate", > > .cra_driver_name =3D "hisi-deflate-acomp", > > + .cra_flags =3D CRYPTO_ALG_ASYNC, > > .cra_module =3D THIS_MODULE, > > .cra_priority =3D HZIP_ALG_PRIORITY, > > .cra_ctxsize =3D sizeof(struct hisi_zip_ctx), > > diff --git a/drivers/crypto/intel/iaa/iaa_crypto_main.c b/drivers/crypt= o/intel/iaa/iaa_crypto_main.c > > index dfd3baf0a8d8..91adf9d76a2e 100644 > > --- a/drivers/crypto/intel/iaa/iaa_crypto_main.c > > +++ b/drivers/crypto/intel/iaa/iaa_crypto_main.c > > @@ -1916,6 +1916,7 @@ static struct acomp_alg iaa_acomp_fixed_deflate = =3D { > > .base =3D { > > .cra_name =3D "deflate", > > .cra_driver_name =3D "deflate-iaa", > > + .cra_flags =3D CRYPTO_ALG_ASYNC, > > .cra_ctxsize =3D sizeof(struct iaa_compression= _ctx), > > .cra_module =3D THIS_MODULE, > > .cra_priority =3D IAA_ALG_PRIORITY, > > Good catch. I think this should go into a separate bug-fix patch. done. > > > diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h > > index 574cffc90730..07bd8f6bc79a 100644 > > --- a/include/crypto/acompress.h > > +++ b/include/crypto/acompress.h > > @@ -160,6 +160,11 @@ static inline void acomp_request_set_tfm(struct ac= omp_req *req, > > req->base.tfm =3D crypto_acomp_tfm(tfm); > > } > > > > +static inline u32 crypto_acomp_get_alg_flags(struct crypto_acomp *tfm) > > +{ > > + return crypto_tfm_alg_flags(crypto_acomp_tfm(tfm)); > > +} > > Sorry, my mistake. I shouldn't have suggested copying skcipher > since that gets the tfm flags as opposed to the alg flags which > you've found out. no worries, Herbert :-) > > I think you should just go with your original function acomp_is_async > but do it like this: > > static inline bool acomp_is_async(struct crypto_acomp *tfm) > { > return crypto_comp_alg_common(tfm)->base.cra_flags & > CRYPTO_ALG_ASYNC; > } ok, I will do that. Besides, i'm also curious if we can open a discussion, for example, letting offload drivers be able to work in both sync mode and async. A scenario I can imagine is as below, for zswap, and page size is configured as 4KiB. in this case, offload hardware might be able to compress/decompress much faster than CPU, but the event-wait, wake-up, schedule latency might add the total time for a compression and decompression. thus offload might work worse than CPU though hardware-accelerator is much faster than CPU. In this case, it seems good to let offload drivers poll the completion of compression and decompression compared with sleep and wait. On the other hand, when PAGE SIZE is big, for example, ARM64's PAGE_SIZE could be 64KiB. in the future, mTHP/large folios project might also ask for larger data to be swapped as a whole. we will only need a schedule/ wake-up for 64KiB or larger data, the compression/ decompression time is much longer, in this case, async mode might help to decrease CPU usage while providing lower comp/decomp latency. So it could be something like: if data is short, acomp driver works by polling; if data is long, acomp driver works by sleeping and waiting. it would be perfect if Zhou or Yang Shen can help collect some data to back up the discussion. > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Thanks Barry