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 12B2BA2EFC for ; Tue, 15 Oct 2019 17:00:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 301791C08E; Tue, 15 Oct 2019 17:00:05 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00056.outbound.protection.outlook.com [40.107.0.56]) by dpdk.org (Postfix) with ESMTP id 055841C067 for ; Tue, 15 Oct 2019 17:00:04 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BuBAmNqbZhNh46x1z+tMW8AgoWih/0rHDcxM/r1xJkiP2uu03AwRZ9WnNSC/TM1mo1lFfkF9u5yw8CY0S9OW5MZon54V+LfDmqqNiNLvEwyiVuDU//GPkCQ29odZMFmOISkfjeJgnZ8VYjIZQEH2HuypdYsHxu3eBA82a32pf60VHVr1yN+GFmy6RkbgVyRNVWidV9KcYX2jLvewAj9fs+egdQuGAPQF1uVJaENGwhr6uTXeqqLNAcR3SQshXW0Mpsmc5f6Bft1i9ZBBTeF4cugAj4UfUrzrxR+a2XAPLiIk4EHOfflFJrNI933ioFbQURChM4I88Rn4PQs31wASxg== 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=trfljhOGvTBvW2+bhAbVwEk8FuFrxO80YlQttwX38zM=; b=ZWAe0giN2ZfxcPtFkhBjtSyJ8oHOgKoBiS7N8HzYpefFP0y1FwFuO4Wpsmj1hyRZXoM3JYRpdQuhpNU9/s0Bfea3FozsC6y9Cd+wb0ALBQ3t8oLOwKLWjqCUpRFYO8O3xDKUH9m8IZB8kfVHobCWiRckIgV/hrmagXmmfEmc3zlAqmQeayOlc4LOM9GGPg6LPxP9Xz7PzQdFqPaVEXAEspWOEPRnLniuv8fQHt6QLyw+xohAZmA5EjvYDfiFmbD464gVWfFQAjl8p5+QoxDFYpbafcIkJ9iJ82Rie++VlgAW3Ipw+Bx3/W/GCeSTHEFxf+8uKanG3rPY1lSn4uNesA== 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=trfljhOGvTBvW2+bhAbVwEk8FuFrxO80YlQttwX38zM=; b=hzQVWKaRkshU2hU5HmSD9KRFz3OcClX3TNpFSRHNTZxPGefnURU1m+FQ0sUyUkNaimZJt7K5U0bpO/CsVT8vcsvgHCKEV133WDliVSDOKXUeho4bst0dZAnZNuU6IghefJBnMihXB2kStOk6eouKzLq0hHLyL7CxpJEvMLLsOZM= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (10.255.118.11) by VE1PR04MB6704.eurprd04.prod.outlook.com (20.179.235.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Tue, 15 Oct 2019 15:00:02 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee%5]) with mapi id 15.20.2347.023; Tue, 15 Oct 2019 15:00:02 +0000 From: Akhil Goyal To: "Zhang, Roy Fan" , "Ananyev, Konstantin" , "'dev@dpdk.org'" , "De Lara Guarch, Pablo" , 'Thomas Monjalon' , "Doherty, Declan" CC: 'Anoob Joseph' Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4LqyJkewM9NkuUWAfAmrqx1acbUiZggAAsN4CAAtsIgIAAT02AgAYXC5CAAbSDgIABbRGggAaWxgCAAPjG4IABs/OAgAuzNYCAAoY34IAE8G8AgAAH4mCAAbN9gIADA/pwgAZJhgCAAr+oMIAAcucAgAMT0cCAA9M0gIAClRcw Date: Tue, 15 Oct 2019 15:00:02 +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> <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> In-Reply-To: <9F7182E3F746AB4EA17801C148F3C6044C06504A@IRSMSX101.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: 1e4d32b2-6767-4741-886f-08d751805b86 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VE1PR04MB6704: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(366004)(136003)(376002)(396003)(199004)(189003)(51914003)(4326008)(66066001)(11346002)(71190400001)(256004)(26005)(186003)(71200400001)(446003)(476003)(86362001)(316002)(44832011)(66946007)(66476007)(66556008)(64756008)(66446008)(6506007)(14444005)(102836004)(55016002)(9686003)(76116006)(7696005)(6116002)(3846002)(76176011)(14454004)(25786009)(229853002)(5660300002)(52536014)(15650500001)(8676002)(305945005)(7736002)(81156014)(2906002)(74316002)(110136005)(99286004)(486006)(6246003)(33656002)(478600001)(6436002)(8936002)(81166006)(921003)(1121003)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6704; 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: BCL:0; x-microsoft-antispam-message-info: VhF8+HZ3pVoZI8OAm2iCv+0aIuWc4l1RCZygLE3hKbQSuljIRtTRor2vQtplz1RSheRofrKJ5Sf6Rdoo2hh9K3l6lhDAux1tnMd9azzQzgucRAYI8At5LNkcKpfvObXO/fWENuJ5BqUMQzshELMiSQEKaNgVNng6iHbDLD2X6u+kX1Rv3/bDsc5bs0jNeg8ZB+7Y1zzL106SZA9Hc59U/7aVN9J0pD6Bl7Oe+0M+eeHtcmPBDFNHEzfAAsuQ3noyNsCI0QQFUTvRHjyzWCwHvCWvadvZxPHygZW8BOPZglAGdFRwNyQaYDRQRppCVI4M4qPjc/JKYo4fqwaY99hsOWEvSYIAE7KlneWhVWBmiVXfF8YN6LkJMhZUgbBLoHcWTkXJOkya7pGhwmvbi+P5yJjp5tYKxHWLCCYHNI/f4Y4= 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: 1e4d32b2-6767-4741-886f-08d751805b86 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 15:00:02.8462 (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: q1G4P7y5h54hh3Ca4660cMKEqlg/WvTfc2cNl1k365TUbv0AFn+WKmRvktvkcH+P4H72W/Oyu+T7ceKd5ISUPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6704 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 Fan, >=20 > Hi Akhil, >=20 > 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 sense= , as >=20 > 1. rte_security contains inline crypto and lookaside crypto action type a= lready, > adding cpu_crypto action type is reasonable. The argument here is not about cpu-crypto, any SW PMD is nothing but a cpu-= crypto. Hence cryptodev already support that. Here we are concerned only with synchronous processing for crypto workloads= . > 2. rte_security contains the security features may not supported by all d= evices, > such as crypto, ipsec, and PDCP. cpu_crypto follow this category, again c= rypto. I do not get the intent of this comment. Looking at your patchset, what I g= et is, You need a synchronous API for crypto workloads. If sync processing is required for security payloads, we can add a sync API= there as well. I have made that comment before also. We can have sync API in both security= and cryptodev. > 3. placing CPU synchronous crypto API in rte_security is natural - as inl= ine mode > works synchronously, too. However cryptodev doesn't. It is a valid use case for all the cryptodev SW PMDs that there should be a synchronous API for crypto processing and that is wh= at your usecase need.=20 > 4. placing CPU synchronous crypto API in rte_security helps boosting SW c= rypto > performance, I have already provided a simple perf test inside the unit t= est in the > patchset for the user to try out - just comparing its output against DPDK= crypto > perf app output. I don't expect any performance difference while moving this from security t= o cryptodev. Have you done any profiling? > 5. placing CPU synchronous crypto API in cryptodev will never serve HW > 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_b= urst / > dequeue_burst for example), this does not fit in cryptodev's principle. Agreed that it is not for HW PMDs, however the op may be null in those case= s. Why it is against the cryptodev principle? There are some ops which=20 PMDs may or may not support. > 6. placing CPU synchronous crypto API in cryptodev confuses the user, as: > - the session created for async mode may not work in sync mode Why? The whole idea for my conversations on this patchset talks about that. Same session should work for both sync and async processing. > - both enqueue/dequeue and cpu_crypto_process does the same crypto > processing, but one PMD may support only one API (set), the other may sup= port > another, and the third PMD supports both. We have to provide another API = to > let the user query which one to support which. This should be based on a Feature flag. It would be upto the application de= veloper To decide which (sync/async) processing is required for which type of flows= that it is configuring. > - 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 in my idea, in the patchset both = PMDs' > implementations did offload the work to the CPU's special circuit designe= d > dedicated to accelerate the crypto processing. This is specific to Intel SW PMDs only. IMO, if you are talking about SW PM= Ds, openssl can also benefit from this. >=20 > To me cryptodev is the one CPU synchronous crypto API should not go into, > rte_security is. >=20 > Regards, > Fan >=20 Regards, Akhil