From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
"baolin.wang@linaro.org" <baolin.wang@linaro.org>,
Horia Geanta <horia.geanta@nxp.com>,
Aymen Sghaier <aymen.sghaier@nxp.com>,
"David S. Miller" <davem@davemloft.net>,
"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>,
Silvano Di Ninno <silvano.dininno@nxp.com>
Subject: Re: [PATCH v2 09/10] crypto: caam - add crypto_engine support for RSA algorithms
Date: Tue, 14 Jan 2020 14:53:54 +0100 [thread overview]
Message-ID: <20200114135354.GA3088@Red> (raw)
In-Reply-To: <VI1PR04MB4445E44C69277F17CFBDB9128C340@VI1PR04MB4445.eurprd04.prod.outlook.com>
On Tue, Jan 14, 2020 at 10:40:53AM +0000, Iuliana Prodan wrote:
> On 1/14/2020 2:14 AM, Herbert Xu wrote:
> > On Mon, Jan 13, 2020 at 09:48:11AM +0000, Iuliana Prodan wrote:
> >>
> >> Regarding the transfer request to crypto-engine: if sending all requests
> >> to crypto-engine, multibuffer tests, for non-backlogging requests fail
> >> after only 10 requests, since crypto-engine queue has 10 entries.
> >
> > That isn't right. The crypto engine should never refuse to accept
> > a request
> Crypto-engine accepts all request that have the backlog flag, the
> non-backlog are accepted till the configured limit (of 10).
>
> > unless the hardware queue is really full.
> Crypto-engine doesn't check the status of hardware queue.
> The non-backlog requests are dropped after 10 entries.
>
> > Perhaps the
> > crypto engine code needs to be fixed?
> To me, crypto-engine seems to be made for backlogged request, that's why
> I'm sending the non-backlog directly to CAAM. The implicit serialization
> of request in crypto-engine is the bottleneck.
>
> But, as I said before, I want to update crypto-engine to set queue
> length when initialize crypto-engine, and remove serialization of
> requests in crypto-engine by adding knowledge about the underlying hw
> accelerator (number of request that can be processed in parallel).
> I'll send a RFC with my proposal for crypto-engine enhancements.
>
> But, until then, I would like to have a backlogging solution in CAAM driver.
>
Hello
I have already something for queue length and processing in parallel.
I will send it soon.
Regards
next prev parent reply other threads:[~2020-01-14 13:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 1:02 [PATCH v2 00/10] crypto: caam - backlogging support Iuliana Prodan
2020-01-03 1:02 ` [PATCH v2 01/10] crypto: caam - refactor skcipher/aead/gcm/chachapoly {en,de}crypt functions Iuliana Prodan
2020-01-03 1:02 ` [PATCH v2 02/10] crypto: caam - refactor ahash_done callbacks Iuliana Prodan
2020-01-03 1:02 ` [PATCH v2 03/10] crypto: caam - refactor ahash_edesc_alloc Iuliana Prodan
2020-01-03 1:02 ` [PATCH v2 04/10] crypto: caam - refactor RSA private key _done callbacks Iuliana Prodan
2020-01-03 1:02 ` [PATCH v2 05/10] crypto: caam - change return code in caam_jr_enqueue function Iuliana Prodan
2020-01-03 1:02 ` [PATCH v2 06/10] crypto: caam - refactor caam_jr_enqueue Iuliana Prodan
2020-01-08 16:59 ` Horia Geanta
2020-01-03 1:02 ` [PATCH v2 07/10] crypto: caam - support crypto_engine framework for SKCIPHER algorithms Iuliana Prodan
2020-01-10 8:12 ` Horia Geanta
2020-01-03 1:02 ` [PATCH v2 08/10] crypto: caam - add crypto_engine support for AEAD algorithms Iuliana Prodan
2020-01-10 8:31 ` Horia Geanta
2020-01-03 1:02 ` [PATCH v2 09/10] crypto: caam - add crypto_engine support for RSA algorithms Iuliana Prodan
2020-01-10 8:46 ` Horia Geanta
2020-01-13 9:48 ` Iuliana Prodan
2020-01-13 12:21 ` Horia Geanta
2020-01-13 13:06 ` Iuliana Prodan
2020-01-14 0:14 ` Herbert Xu
2020-01-14 10:40 ` Iuliana Prodan
2020-01-14 13:53 ` Corentin Labbe [this message]
2020-01-03 1:02 ` [PATCH v2 10/10] crypto: caam - add crypto_engine support for HASH algorithms Iuliana Prodan
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=20200114135354.GA3088@Red \
--to=clabbe.montjoie@gmail.com \
--cc=aymen.sghaier@nxp.com \
--cc=baolin.wang@linaro.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=iuliana.prodan@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.