From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0B68FA04A2; Wed, 6 Nov 2019 11:14:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5D0AC1C042; Wed, 6 Nov 2019 11:14:23 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8DBEA1C010; Wed, 6 Nov 2019 11:14:21 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 06 Nov 2019 02:14:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,274,1569308400"; d="scan'208";a="205281155" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga003.jf.intel.com with ESMTP; 06 Nov 2019 02:14:19 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by IRSMSX108.ger.corp.intel.com ([169.254.11.131]) with mapi id 14.03.0439.000; Wed, 6 Nov 2019 10:14:18 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon , "techboard@dpdk.org" CC: Honnappa Nagarahalli , "dev@dpdk.org" , "Zhang, Roy Fan" , "Doherty, Declan" , "Akhil.goyal@nxp.com" , nd Thread-Topic: [dpdk-techboard] [RFC 0/4] cpu-crypto API choices Thread-Index: AQHVlAi1pOd0g2NJbEaaheJ9I0jiNKd9lJIAgABOV4CAAAOZAIAAAmeA Date: Wed, 6 Nov 2019 10:14:17 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C80AF1@IRSMSX104.ger.corp.intel.com> References: <20191105184122.15172-1-konstantin.ananyev@intel.com> <14706326.cJyEje8106@xps> <2392085.VtZaC0aJ27@xps> In-Reply-To: <2392085.VtZaC0aJ27@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjg0YWZhYTMtMTE3Ny00ZjVmLTllNmEtZGU5MTMyNDFlZmI1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoicjQzekduSVF2Rjk1Z3dQWTh4aVVCY2lxQmRNMDdKc2g4a3ZQeXBpQ2haZ0JiTG5wK3BUdXFLV3crTU51WWxQUCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-techboard] [RFC 0/4] cpu-crypto API choices 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > > > > Originally both SW and HW crypto PMDs use rte_crypot_op based API t= o > > > > process the crypto workload asynchronously. This way provides unifo= rmity to > > > > both PMD types, but also introduce unnecessary performance penalty = to SW > > > > PMDs that have to "simulate" HW async behavior (crypto-ops > > > > enqueue/dequeue, HW addresses computations, storing/dereferencing u= ser > > > > provided data (mbuf) for each crypto-op, etc). > > > > > > > > The aim is to introduce a new optional API for SW crypto-devices to= perform > > > > crypto processing in a synchronous manner. > > > > As summarized by Akhil, we need a synchronous API to perform crypto > > > > operations on raw data using SW PMDs, that provides: > > > > - no crypto-ops. > > > > - avoid using mbufs inside this API, use raw data buffers instead. > > > > - no separate enqueue-dequeue, only single process() API for data = path. > > > > - input data buffers should be grouped by session, > > > > i.e. each process() call takes one session and group of input bu= ffers > > > > that belong to that session. > > > > - All parameters that are constant accross session, should be stor= ed > > > > inside the session itself and reused by all incoming data buffer= s. > > > > > > > > While there seems no controversy about need of such functionality, = there > > > > seems to be no agreement on what would be the best API for that. > > > > So I am requesting for TB input on that matter. > > > > > > > > Series structure: > > > > - patch #1 - intorduce basic data structures to be used by sync API > > > > (no controversy here, I hope ..) > > > > [RFC 1/4] cpu-crypto: Introduce basic data structures > > > > - patch #2 - Intel initial approach for new API (via rte_security) > > > > [RFC 2/4] security: introduce cpu-crypto API > > > > - patch #3 - approach that reuses existing rte_cryptodev API as muc= h as > > > > possible > > > > [RFC 3/4] cryptodev: introduce cpu-crypto API > > > > - patch #4 - approach via introducing new session data structure an= d API > > > > [RFC 4/4] cryptodev: introduce rte_crypto_cpu_sym_session API > > > > > > > > Patches 2,3,4 are mutually exclusive, > > > > and we probably have to choose which one to go forward with. > > > > I put some explanations in each of the patches, hopefully that will= help to > > > > understand pros and cons of each one. > > > > > > > > Akhil strongly supports #3, AFAIK mainly because it allows PMDs to = reuse > > > > existing API and minimize API level changes. > > > > > > IMO, from application perspective, it should not matter who (CPU or a= n accelerator) does the crypto functionality. It just needs to know > if the result will be returned synchronously or asynchronously. > > > > We already have asymmetric and symmetric APIs. > > Here you are proposing a third method: symmetric without mbuf for CPU P= MDs >=20 > Sorry, for this garbage, I am mixing synchronous/asynchronous and symmetr= ic/asymmetric. >=20 > > > > My favorite is #4, #2 is less preferable but ok too. > > > > #3 seems problematic to me by the reasons I outlined in #4 patch de= scription. > > > > > > > > Please provide your opinion. > > > > It means the API is not PMD agnostic, right? Probably not... Because inside DPDK we don't have any other abstraction for SW crypto-libs except vdev, we do need dev_id to get session initialization point. After that I believe all operations can be session based. =20 > So the question is to know if a synchronous API will be implemented only = for CPU virtual PMDs? I don't expect lookaside devices to benefit from sync mode. I think performance penalty would be too high. Konstantin