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 B98825585 for ; Thu, 17 Nov 2016 18:53:02 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 17 Nov 2016 09:53:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,506,1473145200"; d="scan'208";a="902581703" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 17 Nov 2016 09:53:00 -0800 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Nov 2016 17:53:00 +0000 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.248]) by irsmsx155.ger.corp.intel.com ([169.254.14.237]) with mapi id 14.03.0248.002; Thu, 17 Nov 2016 17:52:59 +0000 From: "Trahe, Fiona" To: "dev@dpdk.org" CC: "De Lara Guarch, Pablo" , "Griffin, John" , "Jastrzebski, MichalX K" , "Kusztal, ArkadiuszX" , "Trahe, Fiona" Thread-Topic: [PATCH] crypto: remove unused digest-appended feature Thread-Index: AQHSQPi5wEw302b060usRJGa1W/59qDddAZQ Date: Thu, 17 Nov 2016 17:52:59 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589136390@IRSMSX101.ger.corp.intel.com> References: <1479403997-15437-1-git-send-email-fiona.trahe@intel.com> In-Reply-To: <1479403997-15437-1-git-send-email-fiona.trahe@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWZhNjVmZDItNDcwNy00MzFjLTg5ZGUtMzYyYzE0MmE4ZDhiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ikl1Mnd5QVJNZk13Rmh3Q0pLZWtnaG9CbU9iYkQ5VENvVDBkZmZqYWRQS3M9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] crypto: remove unused digest-appended feature X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 17:53:03 -0000 Note, this is a cover letter - see important clarification below. Sorry, I missed adding the [PATCH 0/1] and [PATCH 1/1] to the email subject= . > -----Original Message----- > From: Trahe, Fiona > Sent: Thursday, November 17, 2016 5:33 PM > To: dev@dpdk.org > Cc: De Lara Guarch, Pablo ; Trahe, Fiona > ; Griffin, John ; Jastrzeb= ski, > MichalX K ; Kusztal, ArkadiuszX > > Subject: [PATCH] crypto: remove unused digest-appended feature >=20 > The cryptodev API had specified that if the digest address field was > left empty on an authentication operation, then the PMD would assume > the digest was appended to the source or destination data. > This case was not handled at all by most PMDs and incorrectly handled > by the QAT PMD. > As no bugs were raised, it is assumed to be not needed, so this patch > removes it, rather than add handling for the case on all PMDs. > The digest can still be appended to the data, but its > address must now be provided in the op. >=20 > I've added this cover letter to pre-empt the question which will arise > in chained-mbuf case. > (Chained-mbuf support will be added in next few weeks for 17.02) > In a chained-mbuf case, if the digest is appended to the data, it could > in theory end up split across the last 2 mbufs. Using the digest address > field only works for the case where the digest is in a flat buffer. The > digest-appended feature would have provided one way of handling this, > pushing the responsibility down to the PMD to follow the chain to find > the digest address and handle it whether in 1 or 2 mbufs. > However, this is adding extra cycles on the data path in all PMDs > to handle a case which may not arise in many applications. > The alternative is to give the application the responsibility > to make sure the digest is in a flat buffer. > Specifically if an application knows cases of a digest spanning > buffers can arise, then it can check for this case and memcpy the partial > start of the digest from the second last buffer into the last buffer > so it's no longer split. > Does anyone see a problem with this? >=20 >=20 > Fiona Trahe (1): > crypto: remove unused digest-appended feature >=20 > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 2 ++ > drivers/crypto/qat/qat_crypto.c | 18 +----------------- > lib/librte_cryptodev/rte_crypto_sym.h | 10 +--------- > 3 files changed, 4 insertions(+), 26 deletions(-) >=20 > -- > 2.5.0