From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: "alexandre.torgue@st.com" <alexandre.torgue@st.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
"mripard@kernel.org" <mripard@kernel.org>,
"wens@csie.org" <wens@csie.org>,
Horia Geanta <horia.geanta@nxp.com>,
Aymen Sghaier <aymen.sghaier@nxp.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-stm32@st-md-mailman.stormreply.com"
<linux-stm32@st-md-mailman.stormreply.com>,
"linux-sunxi@googlegroups.com" <linux-sunxi@googlegroups.com>
Subject: Re: [PATCH RFC 06/10] crypto: engine: introduce ct
Date: Thu, 16 Jan 2020 14:21:07 +0100 [thread overview]
Message-ID: <20200116132107.GB26487@Red> (raw)
In-Reply-To: <VI1PR04MB44455F7F7830159B6ED336648C360@VI1PR04MB4445.eurprd04.prod.outlook.com>
On Thu, Jan 16, 2020 at 11:34:19AM +0000, Iuliana Prodan wrote:
> On 1/14/2020 4:00 PM, Corentin Labbe wrote:
> > We will store the number of request in a batch in engine->ct.
> > This patch adds all loop to unprepare all requests of a batch.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > crypto/crypto_engine.c | 30 ++++++++++++++++++------------
> > include/crypto/engine.h | 2 ++
> > 2 files changed, 20 insertions(+), 12 deletions(-)
> >
> > diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
> > index b72873550587..591dea5ddeec 100644
> > --- a/crypto/crypto_engine.c
> > +++ b/crypto/crypto_engine.c
> > @@ -28,6 +28,7 @@ static void crypto_finalize_request(struct crypto_engine *engine,
> > bool finalize_cur_req = false;
> > int ret;
> > struct crypto_engine_ctx *enginectx;
> > + int i = 0;
> >
> > spin_lock_irqsave(&engine->queue_lock, flags);
> > if (engine->cur_reqs[0].req == req)
> You're checking here just the first request, but do the completion for
> all? Why? Shouldn't we check for each request if it was done by hw or not?
The first request is a sort of key for the whole batch.
>
> I've also seen that the do_one_request is called only on the first
> request, from the batch.
Since the request are linked, this is not a problem.
But I miss this explanaition in the code.
>
> In your driver you do the prepare/unprepare for the whole batch at once,
> but not all drivers, who uses crypto-engine, are doing this (see virtio,
> amlogic, stm32). And I don't know if they can...
prepare is optionnal, and unprepare is optional even if prepare is done.
Furthermore, doing prepare/unprepare is optional per request.
I have tested this serie on sun8i-ss and amlogic which dont use prepare/unprepare.
WARNING: multiple messages have this Message-ID (diff)
From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
Horia Geanta <horia.geanta@nxp.com>,
"linux-sunxi@googlegroups.com" <linux-sunxi@googlegroups.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mripard@kernel.org" <mripard@kernel.org>,
"linux-stm32@st-md-mailman.stormreply.com"
<linux-stm32@st-md-mailman.stormreply.com>,
"wens@csie.org" <wens@csie.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"alexandre.torgue@st.com" <alexandre.torgue@st.com>
Subject: Re: [PATCH RFC 06/10] crypto: engine: introduce ct
Date: Thu, 16 Jan 2020 14:21:07 +0100 [thread overview]
Message-ID: <20200116132107.GB26487@Red> (raw)
In-Reply-To: <VI1PR04MB44455F7F7830159B6ED336648C360@VI1PR04MB4445.eurprd04.prod.outlook.com>
On Thu, Jan 16, 2020 at 11:34:19AM +0000, Iuliana Prodan wrote:
> On 1/14/2020 4:00 PM, Corentin Labbe wrote:
> > We will store the number of request in a batch in engine->ct.
> > This patch adds all loop to unprepare all requests of a batch.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > crypto/crypto_engine.c | 30 ++++++++++++++++++------------
> > include/crypto/engine.h | 2 ++
> > 2 files changed, 20 insertions(+), 12 deletions(-)
> >
> > diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
> > index b72873550587..591dea5ddeec 100644
> > --- a/crypto/crypto_engine.c
> > +++ b/crypto/crypto_engine.c
> > @@ -28,6 +28,7 @@ static void crypto_finalize_request(struct crypto_engine *engine,
> > bool finalize_cur_req = false;
> > int ret;
> > struct crypto_engine_ctx *enginectx;
> > + int i = 0;
> >
> > spin_lock_irqsave(&engine->queue_lock, flags);
> > if (engine->cur_reqs[0].req == req)
> You're checking here just the first request, but do the completion for
> all? Why? Shouldn't we check for each request if it was done by hw or not?
The first request is a sort of key for the whole batch.
>
> I've also seen that the do_one_request is called only on the first
> request, from the batch.
Since the request are linked, this is not a problem.
But I miss this explanaition in the code.
>
> In your driver you do the prepare/unprepare for the whole batch at once,
> but not all drivers, who uses crypto-engine, are doing this (see virtio,
> amlogic, stm32). And I don't know if they can...
prepare is optionnal, and unprepare is optional even if prepare is done.
Furthermore, doing prepare/unprepare is optional per request.
I have tested this serie on sun8i-ss and amlogic which dont use prepare/unprepare.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-16 13:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 13:59 [PATCH RFC 00/10] crypto: engine: permit to batch requests Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 01/10] crypto: sun8i-ce: move iv data to request context Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 02/10] crypto: sun8i-ce: increase task list size Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 03/10] crypto: sun8i-ce: split into prepare/run/unprepare Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 04/10] crypto: sun8i-ce: introduce the slot number Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 05/10] crypto: engine: transform cur_req in an array Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-16 11:34 ` Iuliana Prodan
2020-01-16 11:34 ` Iuliana Prodan
2020-01-14 13:59 ` [PATCH RFC 06/10] crypto: engine: introduce ct Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-16 11:34 ` Iuliana Prodan
2020-01-16 11:34 ` Iuliana Prodan
2020-01-16 13:21 ` Corentin Labbe [this message]
2020-01-16 13:21 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 07/10] crypto: sun8i-ce: handle slot > 0 Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 08/10] crypto: engine: add slot parameter Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-14 13:59 ` [PATCH RFC 09/10] crypto: engine: permit to batch requests Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-16 11:34 ` Iuliana Prodan
2020-01-16 11:34 ` Iuliana Prodan
2020-01-17 16:13 ` Iuliana Prodan
2020-01-17 16:13 ` Iuliana Prodan
2020-01-14 13:59 ` [PATCH RFC 10/10] crypto: sun8i-ce: use the new batch mechanism Corentin Labbe
2020-01-14 13:59 ` Corentin Labbe
2020-01-16 11:33 ` [PATCH RFC 00/10] crypto: engine: permit to batch requests Iuliana Prodan
2020-01-16 11:33 ` Iuliana Prodan
2020-01-16 13:16 ` Corentin Labbe
2020-01-16 13:16 ` Corentin Labbe
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=20200116132107.GB26487@Red \
--to=clabbe.montjoie@gmail.com \
--cc=alexandre.torgue@st.com \
--cc=aymen.sghaier@nxp.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=iuliana.prodan@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-sunxi@googlegroups.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mripard@kernel.org \
--cc=wens@csie.org \
/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.