From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 9834A37AC for ; Mon, 4 Sep 2017 12:08:00 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 03:07:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,474,1498546800"; d="scan'208";a="896887983" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by FMSMGA003.fm.intel.com with ESMTP; 04 Sep 2017 03:07:58 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.22]) by IRSMSX103.ger.corp.intel.com ([169.254.3.49]) with mapi id 14.03.0319.002; Mon, 4 Sep 2017 11:07:57 +0100 From: "Zhang, Roy Fan" To: "De Lara Guarch, Pablo" CC: "dev@dpdk.org" , "Zhang, Roy Fan" Thread-Topic: [dpdk-dev] [PATCH 1/8] crypto/aesni_gcm: do not append digest Thread-Index: AQHTGDWqbSlaISjCIkiVV1fk0/1I+qKkmNRw Date: Mon, 4 Sep 2017 10:07:57 +0000 Message-ID: <9F7182E3F746AB4EA17801C148F3C60433038538@IRSMSX101.ger.corp.intel.com> References: <20170818072103.1416-1-pablo.de.lara.guarch@intel.com> <20170818072103.1416-2-pablo.de.lara.guarch@intel.com> In-Reply-To: <20170818072103.1416-2-pablo.de.lara.guarch@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWVjZjJiOWEtMTRlNy00YjNlLWExYjAtYzQwZDhmNjc3NWQ4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Im4yZXVUdG1OaklRVncxMFBHY3EzRm9aZys1NkhxYktnTlVZQXRZSnZpbmM9In0= dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/8] crypto/aesni_gcm: do not append digest X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 10:08:01 -0000 Hi Pablo, Thanks for the patch. It is very good idea of allocating only necessary buf= fer 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 ; > jerin.jacob@caviumnetworks.com > Cc: dev@dpdk.org; De Lara Guarch, Pablo > Subject: [dpdk-dev] [PATCH 1/8] crypto/aesni_gcm: do not append digest >=20 > 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 th= e > digest generated by the driver, so it can be compared with the one provid= ed > in the crypto operation, without needing to touch the input buffer. >=20 > Signed-off-by: Pablo de Lara > --- > 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(-) >=20 > 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 =3D=3D > AESNI_GCM_OP_AUTHENTICATED_DECRYPTION) { > - uint8_t *auth_tag =3D (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 ne= cessary here. Although the "&" here seems to be wrong. auth_tag didn't poin= t to qp->tmp_digest but a buffer with the address as &qp->tmp_digest. > + uint8_t *auth_tag =3D (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 =3D (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.=20 > + uint8_t *auth_tag =3D (uint8_t *)&qp->temp_digest; >=20 > 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 =3D op->sym->m_dst ? op->sym->m_dst : op- > >sym->m_src; > - > op->status =3D RTE_CRYPTO_OP_STATUS_SUCCESS; >=20 > /* Verify digest if required */ > @@ -397,8 +382,7 @@ post_process_gcm_crypto_op(struct rte_crypto_op > *op, > session->op =3D=3D AESNI_GMAC_OP_VERIFY) { > uint8_t *digest; >=20 Same here. > - uint8_t *tag =3D rte_pktmbuf_mtod_offset(m, uint8_t *, > - m->data_len - session->digest_length); > + uint8_t *tag =3D (uint8_t *)&qp->temp_digest; >=20 ... >=20 > -- > 2.9.4 The same problem lies the rest of your patches in the patchset. Regards, Fan