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 81267A2EEB for ; Tue, 10 Sep 2019 12:44:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2CA931EDE8; Tue, 10 Sep 2019 12:44:37 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40052.outbound.protection.outlook.com [40.107.4.52]) by dpdk.org (Postfix) with ESMTP id 3D95911A2 for ; Tue, 10 Sep 2019 12:44:33 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GTNMrXK3zLbdGd5jZyoPgd0qbMooW+06B4wATDQchrk3ZsJbYfkMADfibpka3bXV0AfjCf7KR88YkiglteZA3ugK7PcSWPjExlK9dJ2gQY01tFtoQ3KDxBpf2EadiJ3Mu7033j8E2WTlTwmsE+gxoyudgJJiJSLwn3Yf6DRJF7mNgNmd6etfdWHTMaitmQ5Rx7e4W6L22rQKqoXaR+11DvGN0GILuvSFkAKue7uA50LdGQpbxPuDMJvLK4aPloCM37d2cRRbJ70z/iXvkagzSXQrvP0fcCUiiuBnPMEY6GfLmPoaeTdP9IVNcqyMQAi+doVq+Act99KMq37Axws7BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3KGzraAqmaRITPuT1Bd5n5PLwHqvioDY1cJNfrtje7s=; b=gSd/WdqlMNzJma9TAxf8ubwym96cvYduJt1DT5sXoowOzeEEz5lYuP9vmyHUK1ffaQLdD/R5LCnnxc/xnt/E3RESSw/mJG2rGLgnVqvgohaJOM1enUOYync6QJ3rOPQno1DB2DnbFvyav5fhLMjSpLDA7ku+qfUvYmfw6EcHH8AzVyCi7roHr9s+tcNvDvCUoJsHPd3QQjj17xnirjGcFF8C9Xamgk+XQf7c+Cb2w1j6EzfzF+qkIifCnacRmT58q2fDQLhZqBwCmm8kFC5yJNMt3Zwz+YZiCL4JYSdfBwNzBDTiBhmIvRlLLDDFpo41i4Xfv7IFZcq5dEJ9AwvQlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3KGzraAqmaRITPuT1Bd5n5PLwHqvioDY1cJNfrtje7s=; b=WMu68u56sz2lWwKSOkYXxK4z1WYJie93nu9Kw7PSYY0NrmBenGHiHsvi+GtroEQAmzbF8Rwn2yHSQp718M1+ip1OT7HZzPe4v4ejjbF2kC1ZcquGPLcLgpA0RzNdxsdpsxfwTXpcWhgILH4VkE2KiOcARHONvOEBvDGjKuf2d6Y= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6381.eurprd04.prod.outlook.com (20.179.232.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.15; Tue, 10 Sep 2019 10:44:32 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::7092:d719:df0b:2b70]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::7092:d719:df0b:2b70%7]) with mapi id 15.20.2241.018; Tue, 10 Sep 2019 10:44:31 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "Zhang, Roy Fan" , "Doherty, Declan" , "De Lara Guarch, Pablo" Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4LqyJkewM9NkuUWAfAmrqx1acbUiZggAAsN4CAAtsIgIAAT02AgAYXC5A= Date: Tue, 10 Sep 2019 10:44:31 +0000 Message-ID: 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> In-Reply-To: <2601191342CEEE43887BDE71AB9772580191926A17@irsmsx105.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c72f58e2-804d-41c8-76d9-08d735dbdd1c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6381; x-ms-traffictypediagnostic: VE1PR04MB6381: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(136003)(366004)(346002)(396003)(376002)(39860400002)(13464003)(199004)(189003)(229853002)(9686003)(5660300002)(26005)(44832011)(8676002)(64756008)(4326008)(81156014)(8936002)(81166006)(66066001)(74316002)(7736002)(15650500001)(66556008)(66476007)(66946007)(305945005)(71200400001)(2501003)(256004)(14444005)(71190400001)(7696005)(53546011)(6506007)(86362001)(66446008)(2906002)(53936002)(446003)(6246003)(186003)(14454004)(102836004)(99286004)(33656002)(76116006)(6116002)(55016002)(6436002)(3846002)(478600001)(316002)(25786009)(54906003)(486006)(476003)(110136005)(52536014)(76176011)(11346002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6381; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5HB+20aHSoQAkVffUt34F+R4prp5N8UMwKFjA6W1YVzNhJdk4ymZo6pHv83+NDsUjQiVmbP+Nf8C0p6X6kCUcfa5LtpEfYWo3xuUs1ZfDWS8eXu+9kIa+RwsazvfSIgaZgpSi0FWwUkXw/lrmqCksaAsWAt/PG20EO04OP4+7qk24F6J4ZzV3In/eRmwmPAeF46SUUhrce2cla4WR3x7Hvcjk2Uktw+nw3QPdeGTm7F4vJDaW5KPIIhduMf6HvjNrakM+GWyITfs46FrdY5fPcTSh6ICt7zUO16HndkKHSrRJ+BnKgpH6521eK5aziDjKkGFZ7ihJgX3Qh1+GtbP2nHvDcZ0x8J+S/ARkFkytwH8MGbVjMVsk901etzxKXZBewwx4eKWINIMk31dhOZsi5JL1sZFUsOiJXZZyfgWY2o= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: c72f58e2-804d-41c8-76d9-08d735dbdd1c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2019 10:44:31.8785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4Yc0EyAn8nfTbRtpt2v1P+qWnm4SnOBKdNiCH+uOSnYG9ehnTuXTlajOFHEN48k1/zPBdB32Pk8cxz7OIjRg5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6381 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" Hi Konstantin, >=20 > Hi Akhil, >=20 > > > This action type allows the burst of symmetric crypto workload using = the > same > > > algorithm, key, and direction being processed by CPU cycles synchrono= usly. > > > This flexible action type does not require external hardware involvem= ent, > > > having the crypto workload processed synchronously, and is more > performant > > > than Cryptodev SW PMD due to the saved cycles on removed "async mode > > > simulation" as well as 3 cacheline access of the crypto ops. > > > > Does that mean application will not call the cryptodev_enqueue_burst an= d > corresponding dequeue burst. >=20 > Yes, instead it just call rte_security_process_cpu_crypto_bulk(...) >=20 > > It would be a new API something like process_packets and it will have t= he > crypto processed packets while returning from the API? >=20 > Yes, though the plan is that API will operate on raw data buffers, not mb= ufs. >=20 > > > > I still do not understand why we cannot do with the conventional crypto= lib > only. > > As far as I can understand, you are not doing any protocol processing o= r any > value add > > To the crypto processing. IMO, you just need a synchronous crypto proce= ssing > API which > > Can be defined in cryptodev, you don't need to re-create a crypto sessi= on in > the name of > > Security session in the driver just to do a synchronous processing. >=20 > I suppose your question is why not to have > rte_crypot_process_cpu_crypto_bulk(...) instead? > The main reason is that would require disruptive changes in existing cryp= todev > API > (would cause ABI/API breakage). > Session for RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO need some extra > information > that normal crypto_sym_xform doesn't contain > (cipher offset from the start of the buffer, might be something extra in = future). Cipher offset will be part of rte_crypto_op. If you intend not to use rte_c= rypto_op You can pass this as an argument in the new cryptodev API. Something extra will also cause ABI breakage in security as well. So it will be same. > Also right now there is no way to add new type of crypto_sym_session with= out > either breaking existing crypto-dev ABI/API or introducing new structure > (rte_crypto_sym_cpu_session or so) for that. What extra info is required in rte_cryptodev_sym_session to get the rte_cry= pto_sym_cpu_session. I don't think there is any. I believe the same crypto session will be able to work synchronously as wel= l. We would only need a new API to perform synchronous actions. That will reduce the duplication = code significantly in the driver to support 2 different kind of APIs with similar code inside.= =20 Please correct me in case I am missing something. > While rte_security is designed in a way that we can add new session types= and > related parameters without causing API/ABI breakage. Yes the intent is to add new sessions based on various protocols that can b= e supported by the driver. It is not that we should find it as an alternative to cryptodev and using i= t just because it will not cause ABI/API breakage. IMO the code should be placed where its intent is. >=20 > BTW, what is your concern with proposed approach (via rte_security)? > From my perspective it is a lightweight change and it is totally optional > for the crypto PMDs to support it or not. > Konstantin >=20 > > > > > > AESNI-GCM and AESNI-MB PMDs are updated with this support. There is a > small > > > performance test app under app/test/security_aesni_gcm(mb)_perftest t= o > > > prove. > > > > > > For the new API > > > The packet is sent to the crypto device for symmetric crypto > > > processing. The device will encrypt or decrypt the buffer based on th= e > session > > > data specified and preprocessed in the security session. Different > > > than the inline or lookaside modes, when the function exits, the user= will > > > expect the buffers are either processed successfully, or having the e= rror > number > > > assigned to the appropriate index of the status array. > > > > > > Will update the program's guide in the v1 patch. > > > > > > Regards, > > > Fan > > > > > > > -----Original Message----- > > > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > > > > Sent: Wednesday, September 4, 2019 11:33 AM > > > > To: Zhang, Roy Fan ; dev@dpdk.org > > > > Cc: Ananyev, Konstantin ; Doherty, > Declan > > > > ; De Lara Guarch, Pablo > > > > > > > > Subject: RE: [RFC PATCH 1/9] security: introduce CPU Crypto action = type > and > > > > API > > > > > > > > Hi Fan, > > > > > > > > > > > > > > This patch introduce new RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > > > > action > > > > > type to security library. The type represents performing crypto > > > > > operation with CPU cycles. The patch also includes a new API to > > > > > process crypto operations in bulk and the function pointers for P= MDs. > > > > > > > > > I am not able to get the flow of execution for this action type. Co= uld you > > > > please elaborate the flow in the documentation. If not in documenta= tion > > > > right now, then please elaborate the flow in cover letter. > > > > Also I see that there are new APIs for processing crypto operations= in bulk. > > > > What does that mean. How are they different from the existing APIs = which > > > > are also handling bulk crypto ops depending on the budget. > > > > > > > > > > > > -Akhil