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 7DAF9A04AB; Wed, 6 Nov 2019 12:33:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 536F11C0C1; Wed, 6 Nov 2019 12:33:49 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 842C01C066; Wed, 6 Nov 2019 12:33:47 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 03:33:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,274,1569308400"; d="scan'208";a="192436766" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga007.jf.intel.com with ESMTP; 06 Nov 2019 03:33:44 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by IRSMSX152.ger.corp.intel.com ([169.254.6.76]) with mapi id 14.03.0439.000; Wed, 6 Nov 2019 11:33:44 +0000 From: "Ananyev, Konstantin" To: "Ananyev, Konstantin" , 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: AQHVlAi1pOd0g2NJbEaaheJ9I0jiNKd9lJIAgABOV4CAAAOZAIAAAmeAgAARAQA= Date: Wed, 6 Nov 2019 11:33:43 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C80F2C@IRSMSX104.ger.corp.intel.com> References: <20191105184122.15172-1-konstantin.ananyev@intel.com> <14706326.cJyEje8106@xps> <2392085.VtZaC0aJ27@xps> <2601191342CEEE43887BDE71AB97725801A8C80AF1@IRSMSX104.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C80AF1@IRSMSX104.ger.corp.intel.com> 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= to > > > > > process the crypto workload asynchronously. This way provides uni= formity to > > > > > both PMD types, but also introduce unnecessary performance penalt= y to SW > > > > > PMDs that have to "simulate" HW async behavior (crypto-ops > > > > > enqueue/dequeue, HW addresses computations, storing/dereferencing= user > > > > > 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 cryp= to > > > > > operations on raw data using SW PMDs, that provides: > > > > > - no crypto-ops. > > > > > - avoid using mbufs inside this API, use raw data buffers instea= d. > > > > > - no separate enqueue-dequeue, only single process() API for dat= a path. > > > > > - input data buffers should be grouped by session, > > > > > i.e. each process() call takes one session and group of input = buffers > > > > > that belong to that session. > > > > > - All parameters that are constant accross session, should be st= ored > > > > > inside the session itself and reused by all incoming data buff= ers. > > > > > > > > > > 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 A= PI > > > > > (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 m= uch as > > > > > possible > > > > > [RFC 3/4] cryptodev: introduce cpu-crypto API > > > > > - patch #4 - approach via introducing new session data structure = and 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 wi= ll help to > > > > > understand pros and cons of each one. > > > > > > > > > > Akhil strongly supports #3, AFAIK mainly because it allows PMDs t= o reuse > > > > > existing API and minimize API level changes. > > > > > > > > IMO, from application perspective, it should not matter who (CPU or= an 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= PMDs > > > > Sorry, for this garbage, I am mixing synchronous/asynchronous and symme= tric/asymmetric. > > > > > > > My favorite is #4, #2 is less preferable but ok too. > > > > > #3 seems problematic to me by the reasons I outlined in #4 patch = description. > > > > > > > > > > Please provide your opinion. > > > > > > It means the API is not PMD agnostic, right? >=20 > Probably not... > Because inside DPDK we don't have any other abstraction for SW crypto-lib= s > 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 onl= y for CPU virtual PMDs? >=20 > I don't expect lookaside devices to benefit from sync mode. > I think performance penalty would be too high. After another thought, if some lookaside PMD would like to support such API= - I think it is still possible: dev_id (or just pointer to internal dev/queue= structure) can be stored inside the session itself. Though I really doubt any lookaside PMD would be interested in such mode. Konstantin=20