RE: [PATCH v13 13/22] crypto: iaa - IAA Batching for parallel compressions/decompressions.

["Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>]

> -----Original Message-----
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Sent: Sunday, November 16, 2025 7:13 PM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org;
> hannes@cmpxchg.org; yosry.ahmed@linux.dev; nphamcs@gmail.com;
> chengming.zhou@linux.dev; usamaarif642@gmail.com;
> ryan.roberts@arm.com; 21cnbao@gmail.com;
> ying.huang@linux.alibaba.com; akpm@linux-foundation.org;
> senozhatsky@chromium.org; sj@kernel.org; kasong@tencent.com; linux-
> crypto@vger.kernel.org; davem@davemloft.net; clabbe@baylibre.com;
> ardb@kernel.org; ebiggers@google.com; surenb@google.com; Accardi,
> Kristen C <kristen.c.accardi@intel.com>; Gomes, Vinicius
> <vinicius.gomes@intel.com>; Feghali, Wajdi K <wajdi.k.feghali@intel.com>;
> Gopal, Vinodh <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v13 13/22] crypto: iaa - IAA Batching for parallel
> compressions/decompressions.
> 
> On Sun, Nov 16, 2025 at 06:53:08PM +0000, Sridhar, Kanchana P wrote:
> >
> > This is a simple/low-overhead implementation that tries to avail of
> > hardware parallelism by launching multiple compress/decompress jobs
> > to the accelerator. Each job runs independently of the other from a
> > driver perspective. For e.g., no assumptions are made in the driver
> > about submission order vis-à-vis completion order. Completions can
> > occur asynchronously.
> >
> > The polling is intended for exactly the purpose you mention, namely,
> > to know when all the sub-requests are complete and to set the sg->length
> > as each sub-request completes. Please let me know if I understood your
> > question correctly.
> 
> The issue here is that this code is being plugged into the acomp
> API, but it isn't implementing the acomp API correctly.  The acomp
> API is supposed to be asynchronous and you should return immediately
> here and then invoke the callback when every sub-request is complete.
> 
> I know that the ultimate user is synchronous, but still the driver
> needs to implement the acomp API correctly.

Thanks Herbert, for this explanation. I think the main problem to solve
is how to signal the callback with the "err" of all sub-requests, noting
which of them are still -EINPROGRESS, vs. having completed with
error/success, set the sg->lengths, etc. I am wondering how this can
be done since I have already returned after submitting the requests..

It seems there needs to be a polling mechanism after returning from
crypto_acomp_compress() once I have submitted the sub-requests.
This polling would ultimately call acomp_request_complete() after all
sub-requests have completed. Do you have any suggestions on how
this can be accomplished?

Thanks,
Kanchana


> 
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt