From: Iuliana Prodan <iuliana.prodan@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Baolin Wang <baolin.wang@linaro.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Corentin Labbe <clabbe.montjoie@gmail.com>,
Horia Geanta <horia.geanta@nxp.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Maxime Ripard <mripard@kernel.org>,
Aymen Sghaier <aymen.sghaier@nxp.com>,
"David S. Miller" <davem@davemloft.net>,
Silvano Di Ninno <silvano.dininno@nxp.com>,
Franck Lenormand <franck.lenormand@nxp.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [RFC PATCH] Crypto-engine support for parallel requests
Date: Tue, 21 Jan 2020 10:08:53 +0000 [thread overview]
Message-ID: <VI1PR04MB444594375C6CAAEE125C65C48C0D0@VI1PR04MB4445.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 20200121091102.magzogr7tnj6joqm@gondor.apana.org.au
On 1/21/2020 11:11 AM, Herbert Xu wrote:
> On Tue, Jan 21, 2020 at 01:32:29AM +0200, Iuliana Prodan wrote:
>>
>> + if (engine->no_reqs < engine->max_no_reqs)
>> + goto retry;
>
> We should not hard-code this number into the engine. Instead,
> we should just let the driver tell us when it is ready to accept
> more requests.
>
This is not hardcoded in crypto-engine.
I've added the crypto_engine_alloc_init_and_set function to configure
how crypto-engine works.
The max_no_req means how many request the driver can process in parallel.
If this doesn't apply on some drivers they can call
crypto_engine_alloc_init, which has max_no_req = 1 - this is the current
behavior. That is serialization of requests by crypto-engine which is a
bottleneck.
> Perhaps we should add a new function for drivers that wish to
> support this that would accept a list of requests instead of
> a single one. It would then process as many requests as it
> can from that list and only return either when the list is
> exhausted or when it can't process any more requests.
>
Linking requests is something different that is not addressed by my
proposal.
I want to remove this serialization, done by crypto-engine, of unrelated
requests.
next prev parent reply other threads:[~2020-01-21 10:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-20 23:32 [RFC PATCH] Crypto-engine support for parallel requests Iuliana Prodan
2020-01-21 9:11 ` Herbert Xu
2020-01-21 10:08 ` Iuliana Prodan [this message]
2020-01-21 10:00 ` Corentin Labbe
2020-01-21 14:20 ` Iuliana Prodan
2020-01-22 10:41 ` Corentin Labbe
2020-01-22 12:29 ` Iuliana Prodan
2020-01-22 13:22 ` Corentin Labbe
2020-01-22 14:41 ` Herbert Xu
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=VI1PR04MB444594375C6CAAEE125C65C48C0D0@VI1PR04MB4445.eurprd04.prod.outlook.com \
--to=iuliana.prodan@nxp.com \
--cc=alexandre.torgue@st.com \
--cc=ard.biesheuvel@linaro.org \
--cc=aymen.sghaier@nxp.com \
--cc=baolin.wang@linaro.org \
--cc=clabbe.montjoie@gmail.com \
--cc=davem@davemloft.net \
--cc=franck.lenormand@nxp.com \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mripard@kernel.org \
--cc=silvano.dininno@nxp.com \
/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;
as well as URLs for NNTP newsgroup(s).