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 78278A3168 for ; Wed, 16 Oct 2019 15:05:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 03A041BF48; Wed, 16 Oct 2019 15:05:02 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id F27EE1BEFA; Wed, 16 Oct 2019 15:04:59 +0200 (CEST) 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; 16 Oct 2019 06:04:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,303,1566889200"; d="scan'208";a="186142926" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga007.jf.intel.com with ESMTP; 16 Oct 2019 06:04:57 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 16 Oct 2019 14:04:56 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by IRSMSX156.ger.corp.intel.com ([169.254.3.227]) with mapi id 14.03.0439.000; Wed, 16 Oct 2019 14:04:56 +0100 From: "Ananyev, Konstantin" To: Akhil Goyal , "Zhang, Roy Fan" , "'dev@dpdk.org'" , "De Lara Guarch, Pablo" , 'Thomas Monjalon' , "Doherty, Declan" CC: 'Anoob Joseph' , Jerin Jacob , Hemant Agrawal , dpdk-techboard Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4Y+AedzaNgY0qWMAmu5GwNVqcbQpEAgAArCICAAuADAIAARA4AgAYiKoCAAbQS0IABqquAgAZiqNCAAPA4gIABtviQgAu3KZCAAoImAIAExwxQgAA3zQCAAZ1E0IADFFEAgAZGHRCAAsIfgIAAUayAgAM4hICAA8fJgIAA1dsggAHHPwCAAYHckA== Date: Wed, 16 Oct 2019 13:04:55 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C698A9@IRSMSX104.ger.corp.intel.com> References: <20190903154046.55992-1-roy.fan.zhang@intel.com> <20190903154046.55992-2-roy.fan.zhang@intel.com> <9F7182E3F746AB4EA17801C148F3C6043369D686@IRSMSX101.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191926A17@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191962CD5@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191966116@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191966C23@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019196A767@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019196D53D@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019196F386@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019197206C@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258019197446B@irsmsx105.ger.corp.intel.com> <9F7182E3F746AB4EA17801C148F3C6044C06504A@IRSMSX101.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725801A8C67CF4@IRSMSX104.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTg3ODE4MDAtN2E5My00NmU0LTk1OTQtZjE0MmZkNjcyMWFhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOVNYZ1wvQWFpNU85SVlrQ0ZOSk5tSHBONjhPZ2RMUU5nMmh4N1wvbnFhTmZrMHRXSkpZSzJ4dENFc3lJS3ZKWGR2In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action 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] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API 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: Akhil Goyal [mailto:akhil.goyal@nxp.com] > Sent: Tuesday, October 15, 2019 4:02 PM > To: Ananyev, Konstantin ; Zhang, Roy Fan ; 'dev@dpdk.org' ; > De Lara Guarch, Pablo ; 'Thomas Monjalon'= ; Doherty, Declan > > Cc: 'Anoob Joseph' ; Jerin Jacob = ; Hemant Agrawal > Subject: RE: [RFC PATCH 1/9] security: introduce CPU Crypto action type a= nd API >=20 >=20 >=20 > > > > > > > Hi Akhil, > > > > > > Thanks for the review and comments! > > > Knowing you are extremely busy. Here is my point in brief: > > > I think placing the CPU synchronous crypto in the rte_security make s= ense, as > > > > > > 1. rte_security contains inline crypto and lookaside crypto action ty= pe already, > > adding cpu_crypto action type is reasonable. > > > 2. rte_security contains the security features may not supported by a= ll devices, > > such as crypto, ipsec, and PDCP. cpu_crypto follow this > > > category, again crypto. > > > 3. placing CPU synchronous crypto API in rte_security is natural - as= inline > > mode works synchronously, too. However cryptodev doesn't. > > > 4. placing CPU synchronous crypto API in rte_security helps boosting = SW > > crypto performance, I have already provided a simple perf test > > > inside the unit test in the patchset for the user to try out - just c= omparing its > > output against DPDK crypto perf app output. > > > 5. placing CPU synchronous crypto API in cryptodev will never serve H= W > > lookaside crypto PMDs, as making them to work synchronously > > > have huge performance penalty. However Cryptodev framework's existing > > design is providing APIs that will work in all crypto PMDs > > > (rte_cryptodev_enqueue_burst / dequeue_burst for example), this does = not fit > > in cryptodev's principle. > > > 6. placing CPU synchronous crypto API in cryptodev confuses the user,= as: > > > - the session created for async mode may not work in sync mode > > > - both enqueue/dequeue and cpu_crypto_process does the same crypto > > processing, but one PMD may support only one API (set), > > > the other may support another, and the third PMD supports both. We ha= ve to > > provide another API to let the user query which one to > > > support which. > > > - two completely different code paths for async/sync mode. > > > 7. You said in the end of the email - placing CPU synchronous crypto = API into > > rte_security is not acceptable as it does not do any > > > rte_security stuff - crypto isn't? You may call this a quibble, but i= n my idea, in > > the patchset both PMDs' implementations did offload the work > > > to the CPU's special circuit designed dedicated to accelerate the cry= pto > > processing. > > > > > > To me cryptodev is the one CPU synchronous crypto API should not go i= nto, > > rte_security is. > > > > I also don't understand why rte_security is not an option here. > > We do have inline-crypto right now, why we can't have cpu-crypto with n= ew > > process() API here? > > Actually would like to hear more opinions from the community here - > > what other interested parties think is the best way for introducing cpu= -crypto > > specific API? >=20 > I have raised this concern in the weekly status meeting as well. But it l= ooks like nobody > is interested. That's really a pity... CC-ing it to TB members, hopefully someone would be interested, or at least can forward to interested person. Konstantin