linux-kernel - Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z3yMNI_DbkKBKJxO@gondor.apana.org.au>
Date: Tue, 7 Jan 2025 10:06:44 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: "Sridhar, Kanchana P" <kanchana.p.sridhar@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"nphamcs@...il.com" <nphamcs@...il.com>,
	"chengming.zhou@...ux.dev" <chengming.zhou@...ux.dev>,
	"usamaarif642@...il.com" <usamaarif642@...il.com>,
	"ryan.roberts@....com" <ryan.roberts@....com>,
	"21cnbao@...il.com" <21cnbao@...il.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"clabbe@...libre.com" <clabbe@...libre.com>,
	"ardb@...nel.org" <ardb@...nel.org>,
	"ebiggers@...gle.com" <ebiggers@...gle.com>,
	"surenb@...gle.com" <surenb@...gle.com>,
	"Accardi, Kristen C" <kristen.c.accardi@...el.com>,
	"Feghali, Wajdi K" <wajdi.k.feghali@...el.com>,
	"Gopal, Vinodh" <vinodh.gopal@...el.com>
Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for
 compress/decompress batching.

On Mon, Jan 06, 2025 at 05:46:01PM -0800, Yosry Ahmed wrote:
>
> For software compressors, the batch size should be 1. In that
> scenario, from a zswap perspective (without going into the acomp
> implementation details please), is there a functional difference? If
> not, we can just use the request chaining API regardless of batching
> if that is what Herbert means.

If you can supply a batch size of 8 for iaa, there is no reason
why you can't do it for software algorithms.  It's the same
reason that we have GSO in the TCP stack, regardless of whether
the hardware can handle TSO.

The amortisation of the segmentation cost means that it will be
a win over-all.

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