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 E5280A04AB; Wed, 6 Nov 2019 16:19:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6BF021C191; Wed, 6 Nov 2019 16:19:31 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F19AC1C18E; Wed, 6 Nov 2019 16:19:28 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 07:19:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,275,1569308400"; d="scan'208";a="402392141" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga005.fm.intel.com with ESMTP; 06 Nov 2019 07:19:26 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by IRSMSX103.ger.corp.intel.com ([169.254.3.139]) with mapi id 14.03.0439.000; Wed, 6 Nov 2019 15:19:25 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: "techboard@dpdk.org" , 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: AQHVlAi1pOd0g2NJbEaaheJ9I0jiNKd9lJIAgABOV4CAAAOZAIAAAmeAgAARAQCAABa3gIAAKsCQ Date: Wed, 6 Nov 2019 15:19:25 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C81358@IRSMSX104.ger.corp.intel.com> References: <20191105184122.15172-1-konstantin.ananyev@intel.com> <2601191342CEEE43887BDE71AB97725801A8C80AF1@IRSMSX104.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725801A8C80F2C@IRSMSX104.ger.corp.intel.com> <2859970.EjbiKIM5I0@xps> In-Reply-To: <2859970.EjbiKIM5I0@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzE1MTMyN2UtOWQ5NS00MmI2LWFjNzktODUxMjhhNmIzODcwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNFc3VTVHZFJkUmhwY2R0ZDhvYnoxOElPN2dlQk8yZlRjbWZrU244a2Y1aUxLbnhTbHJiQ1c4VFQ4akpuSDJQWSJ9 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, November 6, 2019 12:19 PM > To: Ananyev, Konstantin > Cc: techboard@dpdk.org; Honnappa Nagarahalli ; dev@dpdk.org; Zhang, Roy Fan > ; Doherty, Declan ; Ak= hil.goyal@nxp.com; nd > Subject: Re: [dpdk-techboard] [RFC 0/4] cpu-crypto API choices >=20 > 06/11/2019 12:33, Ananyev, Konstantin: > > > > > > > > > Originally both SW and HW crypto PMDs use rte_crypot_op based= API to > > > > > > > process the crypto workload asynchronously. This way provides= uniformity to > > > > > > > both PMD types, but also introduce unnecessary performance pe= nalty to SW > > > > > > > PMDs that have to "simulate" HW async behavior (crypto-ops > > > > > > > enqueue/dequeue, HW addresses computations, storing/dereferen= cing user > > > > > > > provided data (mbuf) for each crypto-op, etc). > > > > > > > > > > > > > > The aim is to introduce a new optional API for SW crypto-devi= ces 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 in= stead. > > > > > > > - 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 in= put buffers > > > > > > > that belong to that session. > > > > > > > - All parameters that are constant accross session, should b= e stored > > > > > > > inside the session itself and reused by all incoming data = buffers. > > > > > > > > > > > > > > While there seems no controversy about need of such functiona= lity, there > > > > > > > seems to be no agreement on what would be the best API for th= at. > > > > > > > So I am requesting for TB input on that matter. > > > > > > > > > > > > > > Series structure: > > > > > > > - patch #1 - intorduce basic data structures to be used by sy= nc 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_secu= rity) > > > > > > > [RFC 2/4] security: introduce cpu-crypto API > > > > > > > - patch #3 - approach that reuses existing rte_cryptodev API = as much as > > > > > > > possible > > > > > > > [RFC 3/4] cryptodev: introduce cpu-crypto API > > > > > > > - patch #4 - approach via introducing new session data struct= ure and API > > > > > > > [RFC 4/4] cryptodev: introduce rte_crypto_cpu_sym_session A= PI > > > > > > > > > > > > > > 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 tha= t will help to > > > > > > > understand pros and cons of each one. > > > > > > > > > > > > > > Akhil strongly supports #3, AFAIK mainly because it allows PM= Ds to reuse > > > > > > > existing API and minimize API level changes. > > > > > > > > > > > > IMO, from application perspective, it should not matter who (CP= U 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 s= ymmetric/asymmetric. > > > > > > > > > > > My favorite is #4, #2 is less preferable but ok too. > > > > > > > #3 seems problematic to me by the reasons I outlined in #4 pa= tch description. > > > > > > > > > > > > > > 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. > > > > > > > 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. > > > > 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/q= ueue structure) > > can be stored inside the session itself. > > Though I really doubt any lookaside PMD would be interested in such mod= e. >=20 > So what should be the logic in the application? > How the combo PMD/API is chosen? Up to the user. At session creation time user has to choose what session he wants to use. Then at data-path he can either call async API (enqueue/dequeue) or sync API (process).=20 I expect users who do care about extra perf will choose cpu-crypto mode when it is available. Existing apps and apps who'd like to have just one code-path would stay with async mode and will be unaffected. =20 > How does it work with the crypto scheduler? If we want to add cpu-crypto support to crypto-scheduler PMD, then changes would be needed anyway, not matter will we choose #3 or #4.=20