From: Iuliana Prodan <iuliana.prodan@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
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>
Cc: 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-kernel@vger.kernel.org,
linux-imx <linux-imx@nxp.com>,
Iuliana Prodan <iuliana.prodan@nxp.com>
Subject: [PATCH v6 3/3] crypto: engine - support for batch requests
Date: Tue, 28 Apr 2020 18:49:05 +0300 [thread overview]
Message-ID: <1588088945-9067-4-git-send-email-iuliana.prodan@nxp.com> (raw)
In-Reply-To: <1588088945-9067-1-git-send-email-iuliana.prodan@nxp.com>
Added support for batch requests, per crypto engine.
A new callback is added, do_batch_requests, which executes a
batch of requests. This has the crypto_engine structure as argument
(for cases when more than one crypto-engine is used).
The crypto_engine_alloc_init_and_set function, initializes
crypto-engine, but also, sets the do_batch_requests callback.
On crypto_pump_requests, if do_batch_requests callback is
implemented in a driver, this will be executed. The link between
the requests will be done in driver, if possible.
do_batch_requests is available only if the hardware has support
for multiple request.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
---
crypto/crypto_engine.c | 27 ++++++++++++++++++++++++++-
include/crypto/engine.h | 5 +++++
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index ee19273..412149e 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -227,6 +227,18 @@ static void crypto_pump_requests(struct crypto_engine *engine,
out:
spin_unlock_irqrestore(&engine->queue_lock, flags);
+
+ /*
+ * Batch requests is possible only if
+ * hardware can enqueue multiple requests
+ */
+ if (engine->do_batch_requests) {
+ ret = engine->do_batch_requests(engine);
+ if (ret)
+ dev_err(engine->dev, "failed to do batch requests: %d\n",
+ ret);
+ }
+
return;
}
@@ -456,6 +468,12 @@ EXPORT_SYMBOL_GPL(crypto_engine_stop);
* crypto-engine queue.
* @dev: the device attached with one hardware engine
* @retry_support: whether hardware has support for retry mechanism
+ * @cbk_do_batch: pointer to a callback function to be invoked when executing a
+ * a batch of requests.
+ * This has the form:
+ * callback(struct crypto_engine *engine)
+ * where:
+ * @engine: the crypto engine structure.
* @rt: whether this queue is set to run as a realtime task
* @qlen: maximum size of the crypto-engine queue
*
@@ -464,6 +482,7 @@ EXPORT_SYMBOL_GPL(crypto_engine_stop);
*/
struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
bool retry_support,
+ int (*cbk_do_batch)(struct crypto_engine *engine),
bool rt, int qlen)
{
struct sched_param param = { .sched_priority = MAX_RT_PRIO / 2 };
@@ -483,6 +502,12 @@ struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
engine->idling = false;
engine->retry_support = retry_support;
engine->priv_data = dev;
+ /*
+ * Batch requests is possible only if
+ * hardware has support for retry mechanism.
+ */
+ engine->do_batch_requests = retry_support ? cbk_do_batch : NULL;
+
snprintf(engine->name, sizeof(engine->name),
"%s-engine", dev_name(dev));
@@ -516,7 +541,7 @@ EXPORT_SYMBOL_GPL(crypto_engine_alloc_init_and_set);
*/
struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
{
- return crypto_engine_alloc_init_and_set(dev, false, rt,
+ return crypto_engine_alloc_init_and_set(dev, false, NULL, rt,
CRYPTO_ENGINE_MAX_QLEN);
}
EXPORT_SYMBOL_GPL(crypto_engine_alloc_init);
diff --git a/include/crypto/engine.h b/include/crypto/engine.h
index b92d7ff..3f06e40 100644
--- a/include/crypto/engine.h
+++ b/include/crypto/engine.h
@@ -37,6 +37,8 @@
* @unprepare_crypt_hardware: there are currently no more requests on the
* queue so the subsystem notifies the driver that it may relax the
* hardware by issuing this call
+ * @do_batch_requests: execute a batch of requests. Depends on multiple
+ * requests support.
* @kworker: kthread worker struct for request pump
* @pump_requests: work struct for scheduling work to the request pump
* @priv_data: the engine private data
@@ -59,6 +61,8 @@ struct crypto_engine {
int (*prepare_crypt_hardware)(struct crypto_engine *engine);
int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
+ int (*do_batch_requests)(struct crypto_engine *engine);
+
struct kthread_worker *kworker;
struct kthread_work pump_requests;
@@ -107,6 +111,7 @@ int crypto_engine_stop(struct crypto_engine *engine);
struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
bool retry_support,
+ int (*cbk_do_batch)(struct crypto_engine *engine),
bool rt, int qlen);
int crypto_engine_exit(struct crypto_engine *engine);
--
2.1.0
next prev parent reply other threads:[~2020-04-28 15:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 15:49 [PATCH v6 0/3] crypto: engine - support for parallel and batch requests Iuliana Prodan
2020-04-28 15:49 ` [PATCH v6 1/3] crypto: algapi - create function to add request in front of queue Iuliana Prodan
2020-04-28 15:49 ` [PATCH v6 2/3] crypto: engine - support for parallel requests based on retry mechanism Iuliana Prodan
2020-04-28 15:49 ` Iuliana Prodan [this message]
2020-05-08 6:05 ` [PATCH v6 0/3] crypto: engine - support for parallel and batch requests 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=1588088945-9067-4-git-send-email-iuliana.prodan@nxp.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).