Message-ID: <SJ0PR11MB567871A712CE2E971B909D93C9282@SJ0PR11MB5678.namprd11.prod.outlook.com>
Date: Wed, 27 Nov 2024 01:22:40 +0000
From: "Sridhar, Kanchana P" <kanchana.p.sridhar@...el.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "hannes@...xchg.org"
	<hannes@...xchg.org>, "yosryahmed@...gle.com" <yosryahmed@...gle.com>,
	"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>,
	"Sridhar, Kanchana P" <kanchana.p.sridhar@...el.com>
Subject: RE: [PATCH v4 01/10] crypto: acomp - Define two new interfaces for
 compress/decompress batching.


> -----Original Message-----
> From: Sridhar, Kanchana P <kanchana.p.sridhar@...el.com>
> Sent: Monday, November 25, 2024 6:37 PM
> To: Herbert Xu <herbert@...dor.apana.org.au>
> Cc: linux-kernel@...r.kernel.org; linux-mm@...ck.org;
> hannes@...xchg.org; yosryahmed@...gle.com; nphamcs@...il.com;
> chengming.zhou@...ux.dev; usamaarif642@...il.com;
> ryan.roberts@....com; 21cnbao@...il.com; akpm@...ux-foundation.org;
> linux-crypto@...r.kernel.org; davem@...emloft.net; clabbe@...libre.com;
> ardb@...nel.org; ebiggers@...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>;
> Sridhar, Kanchana P <kanchana.p.sridhar@...el.com>
> Subject: RE: [PATCH v4 01/10] crypto: acomp - Define two new interfaces for
> compress/decompress batching.
> 
> 
> > -----Original Message-----
> > From: Herbert Xu <herbert@...dor.apana.org.au>
> > Sent: Monday, November 25, 2024 6:14 PM
> > To: Sridhar, Kanchana P <kanchana.p.sridhar@...el.com>
> > Cc: linux-kernel@...r.kernel.org; linux-mm@...ck.org;
> > hannes@...xchg.org; yosryahmed@...gle.com; nphamcs@...il.com;
> > chengming.zhou@...ux.dev; usamaarif642@...il.com;
> > ryan.roberts@....com; 21cnbao@...il.com; akpm@...ux-foundation.org;
> > linux-crypto@...r.kernel.org; davem@...emloft.net;
> clabbe@...libre.com;
> > ardb@...nel.org; ebiggers@...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 v4 01/10] crypto: acomp - Define two new interfaces
> for
> > compress/decompress batching.
> >
> > On Tue, Nov 26, 2024 at 02:13:00AM +0000, Sridhar, Kanchana P wrote:
> > >
> > > I wanted to make sure I understand your suggestion: Are you suggesting
> we
> > > implement request chaining for "struct acomp_req" similar to how this is
> > being
> > > done for "struct ahash_request" in your patch?
> > >
> > > I guess I was a bit confused by your comment about rebasing, which
> would
> > > imply a direct use of the request chaining API you've provided for "crypto
> > hash".
> > > I would appreciate it if you could clarify.
> >
> > Yes I was referring to the generic part of request chaining,
> > and not rebasing acomp on top of ahash.
> 
> Ok, thanks for the clarification! Would it be simpler if you could submit a
> crypto_acomp request chaining patch that I can then use in iaa_crypto?
> I would greatly appreciate this.

Hi Herbert,

I was able to take a more in-depth look at the request chaining you have
implemented in crypto ahash, and I think I have a good understanding of
what needs to be done in crypto acomp for request chaining. I will go ahead
and try to implement this and reach out if I have any questions. 

I would be interested to know the performance impact if we kept the
crypto_wait based chaining of the requests (which makes the request chaining
synchronous IIUC), wrt the asynchronous polling that's currently used for
batching in the iaa_crypto driver. If you have any ideas on introducing
polling to the chaining concept, please do share, I would greatly appreciate
it.

Besides this, some questions that came up as far as applying request chaining
to crypto_acomp_batch_[de]compress were:

1) It appears a calling module like zswap would only be able to get 1 error
     status for all the requests that are chained, as against individual error
     statuses for each of the [de]compress jobs. Is this understanding correct?
2) The request chaining makes use of the req->base.complete and req->base.data,
     which are also used for internal data by the iaa_crypto driver. I can add another
     "void *data1" member to struct crypto_async_request to work around this,
     such that iaa_crypto uses "data1" instead of "data".

Please let me know if you have any suggestions. Also, if you have already begun
working on acomp request chaining, just let me know. I will wait for your patch
in this case (rather than implementing it myself).

Thanks,
Kanchana


> 
> Thanks,
> Kanchana
> 
> 
> >
> > 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

Powered by blists - more mailing lists