From: "Zhang, Roy Fan" <roy.fan.zhang@intel.com>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Zhang, Roy Fan" <roy.fan.zhang@intel.com>
Subject: Re: [dpdk-dev] [PATCH 1/8] crypto/aesni_gcm: do not append digest
Date: Mon, 4 Sep 2017 10:07:57 +0000 [thread overview]
Message-ID: <9F7182E3F746AB4EA17801C148F3C60433038538@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <20170818072103.1416-2-pablo.de.lara.guarch@intel.com>
Hi Pablo,
Thanks for the patch. It is very good idea of allocating only necessary buffer for digests in the operation.
Comments inline:
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Friday, August 18, 2017 8:21 AM
> To: Doherty, Declan <declan.doherty@intel.com>;
> jerin.jacob@caviumnetworks.com
> Cc: dev@dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH 1/8] crypto/aesni_gcm: do not append digest
>
> When performing an authentication verification, the PMD was using memory
> at the end of the input buffer, to store temporarily the digest.
> This operation requires the buffer to have enough tailroom unnecessarily.
> Instead, memory is allocated for each queue pair, to store temporarily the
> digest generated by the driver, so it can be compared with the one provided
> in the crypto operation, without needing to touch the input buffer.
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
> drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 31 +++++-------------------
> drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h | 7 ++++++
> 2 files changed, 13 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> index d9c91d0..ae670a7 100644
> --- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> +++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> @@ -298,14 +298,7 @@ process_gcm_crypto_op(struct aesni_gcm_qp *qp,
> struct rte_crypto_op *op,
> sym_op->aead.digest.data,
> (uint64_t)session->digest_length);
> } else if (session->op ==
> AESNI_GCM_OP_AUTHENTICATED_DECRYPTION) {
> - uint8_t *auth_tag = (uint8_t
> *)rte_pktmbuf_append(sym_op->m_dst ?
> - sym_op->m_dst : sym_op->m_src,
> - session->digest_length);
> -
> - if (!auth_tag) {
> - GCM_LOG_ERR("auth_tag");
> - return -1;
> - }
qp->tmp_digest has already the data type of uint8_t*, the casting is not necessary here. Although the "&" here seems to be wrong. auth_tag didn't point to qp->tmp_digest but a buffer with the address as &qp->tmp_digest.
> + uint8_t *auth_tag = (uint8_t *)&qp->temp_digest;
> qp->ops[session->key].init(&session->gdata_key,
> &qp->gdata_ctx,
> @@ -350,14 +343,7 @@ process_gcm_crypto_op(struct aesni_gcm_qp *qp,
> struct rte_crypto_op *op,
> sym_op->auth.digest.data,
> (uint64_t)session->digest_length);
> } else { /* AESNI_GMAC_OP_VERIFY */
> - uint8_t *auth_tag = (uint8_t
> *)rte_pktmbuf_append(sym_op->m_dst ?
> - sym_op->m_dst : sym_op->m_src,
> - session->digest_length);
> -
> - if (!auth_tag) {
> - GCM_LOG_ERR("auth_tag");
> - return -1;
> - }
Same here.
> + uint8_t *auth_tag = (uint8_t *)&qp->temp_digest;
>
> qp->ops[session->key].init(&session->gdata_key,
> &qp->gdata_ctx,
> @@ -385,11 +371,10 @@ process_gcm_crypto_op(struct aesni_gcm_qp *qp,
> struct rte_crypto_op *op,
> * - Returns NULL on invalid job
> */
> static void
> -post_process_gcm_crypto_op(struct rte_crypto_op *op,
> +post_process_gcm_crypto_op(struct aesni_gcm_qp *qp,
> + struct rte_crypto_op *op,
> struct aesni_gcm_session *session)
> {
> - struct rte_mbuf *m = op->sym->m_dst ? op->sym->m_dst : op-
> >sym->m_src;
> -
> op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
>
> /* Verify digest if required */
> @@ -397,8 +382,7 @@ post_process_gcm_crypto_op(struct rte_crypto_op
> *op,
> session->op == AESNI_GMAC_OP_VERIFY) {
> uint8_t *digest;
>
Same here.
> - uint8_t *tag = rte_pktmbuf_mtod_offset(m, uint8_t *,
> - m->data_len - session->digest_length);
> + uint8_t *tag = (uint8_t *)&qp->temp_digest;
>
...
>
> --
> 2.9.4
The same problem lies the rest of your patches in the patchset.
Regards,
Fan
next prev parent reply other threads:[~2017-09-04 10:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 7:20 [dpdk-dev] [PATCH 0/8] Remove temporary digest allocation Pablo de Lara
2017-08-18 7:20 ` [dpdk-dev] [PATCH 1/8] crypto/aesni_gcm: do not append digest Pablo de Lara
2017-09-04 10:07 ` Zhang, Roy Fan [this message]
2017-09-05 8:49 ` De Lara Guarch, Pablo
2017-08-18 7:20 ` [dpdk-dev] [PATCH 2/8] crypto/armv8: " Pablo de Lara
2017-09-11 5:22 ` Jerin Jacob
2017-08-18 7:20 ` [dpdk-dev] [PATCH 3/8] crypto/openssl: " Pablo de Lara
2017-08-18 7:20 ` [dpdk-dev] [PATCH 4/8] crypto/kasumi: " Pablo de Lara
2017-08-18 7:21 ` [dpdk-dev] [PATCH 5/8] crypto/snow3g: " Pablo de Lara
2017-08-18 7:21 ` [dpdk-dev] [PATCH 6/8] crypto/zuc: " Pablo de Lara
2017-08-18 7:21 ` [dpdk-dev] [PATCH 7/8] crypto/aesni_mb: " Pablo de Lara
2017-08-18 7:21 ` [dpdk-dev] [PATCH 8/8] test/crypto: do not allocate extra memory for digest Pablo de Lara
2017-09-05 2:19 ` [dpdk-dev] [PATCH v2 0/8] Remove temporary digest allocation Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 1/8] crypto/aesni_gcm: do not append digest Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 2/8] crypto/armv8: " Pablo de Lara
2017-09-06 9:02 ` De Lara Guarch, Pablo
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 3/8] crypto/openssl: " Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 4/8] crypto/kasumi: " Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 5/8] crypto/snow3g: " Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 6/8] crypto/zuc: " Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 7/8] crypto/aesni_mb: " Pablo de Lara
2017-09-05 2:20 ` [dpdk-dev] [PATCH v2 8/8] test/crypto: do not allocate extra memory for digest Pablo de Lara
2017-09-05 12:38 ` [dpdk-dev] [PATCH v2 0/8] Remove temporary digest allocation Zhang, Roy Fan
2017-09-11 9:39 ` De Lara Guarch, Pablo
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=9F7182E3F746AB4EA17801C148F3C60433038538@IRSMSX101.ger.corp.intel.com \
--to=roy.fan.zhang@intel.com \
--cc=dev@dpdk.org \
--cc=pablo.de.lara.guarch@intel.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).