linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: "Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: Re: [v2 PATCH 3/7] crypto: acomp - Add request chaining and virtual addresses
Date: Wed, 5 Mar 2025 09:51:24 +0800	[thread overview]
Message-ID: <Z8euHNedFIBkVZmL@gondor.apana.org.au> (raw)
In-Reply-To: <SA3PR11MB81203FD3D6638C0E1259E5DAC9C82@SA3PR11MB8120.namprd11.prod.outlook.com>

On Tue, Mar 04, 2025 at 09:59:59PM +0000, Sridhar, Kanchana P wrote:
>
> > +static int acomp_reqchain_finish(struct acomp_req_chain *state,
> > +				 int err, u32 mask)
> > +{
> > +	struct acomp_req *req0 = state->req0;
> > +	struct acomp_req *req = state->cur;
> > +	struct acomp_req *n;
> > +
> > +	acomp_reqchain_virt(state, err);
> 
> Unless I am missing something, this seems to be future-proofing, based
> on the initial checks you've implemented in acomp_do_req_chain().
> 
> > +
> > +	if (req != req0)
> > +		list_add_tail(&req->base.list, &req0->base.list);
> > +
> > +	list_for_each_entry_safe(req, n, &state->head, base.list) {
> > +		list_del_init(&req->base.list);
> > +
> > +		req->base.flags &= mask;
> > +		req->base.complete = acomp_reqchain_done;
> > +		req->base.data = state;
> > +		state->cur = req;
> > +
> > +		if (acomp_request_isvirt(req)) {
> > +			unsigned int slen = req->slen;
> > +			unsigned int dlen = req->dlen;
> > +			const u8 *svirt = req->svirt;
> > +			u8 *dvirt = req->dvirt;
> > +
> > +			state->src = svirt;
> > +			state->dst = dvirt;
> > +
> > +			sg_init_one(&state->ssg, svirt, slen);
> > +			sg_init_one(&state->dsg, dvirt, dlen);
> > +
> > +			acomp_request_set_params(req, &state->ssg,
> > &state->dsg,
> > +						 slen, dlen);
> > +		}
> > +
> > +		err = state->op(req);
> > +
> > +		if (err == -EINPROGRESS) {
> > +			if (!list_empty(&state->head))
> > +				err = -EBUSY;
> > +			goto out;
> > +		}
> > +
> > +		if (err == -EBUSY)
> > +			goto out;
> 
> This is a fully synchronous way of processing the request chain, and
> will not work for iaa_crypto's submit-then-poll-for-completions paradigm,
> essential for us to process the compressions in parallel in hardware.
> Without parallelism, we will not derive the full benefits of IAA.

This function is not for chaining drivers at all.  It's for existing
drivers that do *not* support chaining.

If your driver supports chaining, then it should not come through
acomp_reqchain_finish in the first place.  The acomp_reqchain code
translates chained requests to simple unchained ones for the
existing drivers.  If the driver supports chaining natively, then
it will bypass all this go straight to the driver, where you can do
whatever you want with the chained request.

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


  reply	other threads:[~2025-03-05  1:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04  9:25 [v2 PATCH 0/7] crypto: acomp - Add request chaining and virtual address support Herbert Xu
2025-03-04  9:25 ` [v2 PATCH 1/7] crypto: api - Add cra_type->destroy hook Herbert Xu
2025-03-04  9:25 ` [v2 PATCH 2/7] crypto: scomp - Remove tfm argument from alloc/free_ctx Herbert Xu
2025-03-04  9:25 ` [v2 PATCH 3/7] crypto: acomp - Add request chaining and virtual addresses Herbert Xu
2025-03-04 21:59   ` Sridhar, Kanchana P
2025-03-05  1:51     ` Herbert Xu [this message]
2025-03-05 20:09       ` Sridhar, Kanchana P
2025-03-04  9:25 ` [v2 PATCH 4/7] crypto: testmgr - Remove NULL dst acomp tests Herbert Xu
2025-03-04  9:25 ` [v2 PATCH 5/7] crypto: scomp - Remove support for most non-trivial destination SG lists Herbert Xu
2025-03-04  9:25 ` [v2 PATCH 6/7] crypto: scomp - Add chaining and virtual address support Herbert Xu
2025-03-04  9:25 ` [v2 PATCH 7/7] crypto: acomp - Move stream management into scomp layer Herbert Xu
2025-03-05  1:46 ` [v2 PATCH 0/7] crypto: acomp - Add request chaining and virtual address support Jonathan Cameron
2025-03-05 21:37 ` Cabiddu, Giovanni
2025-03-06  0:42   ` Herbert Xu
2025-03-06 12:14     ` Cabiddu, Giovanni
2025-03-06  8:15 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8euHNedFIBkVZmL@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=kanchana.p.sridhar@intel.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=yosry.ahmed@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox