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 6D7E0A2EFC for ; Tue, 15 Oct 2019 17:02:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2D0161BF63; Tue, 15 Oct 2019 17:02:23 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00084.outbound.protection.outlook.com [40.107.0.84]) by dpdk.org (Postfix) with ESMTP id C8DB71BF62 for ; Tue, 15 Oct 2019 17:02:21 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S7z2xCupYlVZVeY3lsURh3HKKTf0TFMFmZ7dGXAbw3AaeJV0mZE/n3zTBYuXGh2FgqhcM0dCOpjjd4Aul0HQUcBYnYUzHXiILoIAuZmLJTp10RThdzd/YyTZkRL1+LVgfzMMgffkqKFJVxgnJ4GIjuy77sBVzDPfrdgAeTM52/xeUkMunpiM2s6uUA/n8uVUq0YjrdiXn1V42v37Y0owG4ID68AiYQkK18ypG2GHimBSkEhOZjjGtfiRt8b/QEu6G3AKGD/YJbHj8IE9xxmj3CQGQDRHIwmYaLjvtNcvKM8+fx2UeukxAJrSM1mijkfE+0CVpyfN7ZeD8acnq2rADw== 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=afNpNfmsjxvG4peGmUE17YaoV7zG8Y17b/bMQgHwEpw=; b=W1+kVwPnKxp0MkERaDmQhfshaSHwT5pXW5+Yix95C3segDKICLM8GYCWg2SEA2EFMqSoMv6sLsYkSgDiw/GSmzr4x+qw8BDj4in8tsijGmXBs9BgO6LEkz8vBa40wJ4ZEJvkzuIcFDWW/SQZK4vdhEnWWUUVwfySO5Sy/VIJCMDXMdu9ACptath7mS8jZWuFJmPuC13iVpmH4SESjrblmYueLNhkHOYkhG7svvt+nCpgVj2IComhsleTh1rqbSq19XETcxUKQ//35IeFitl49EVn/QUvayX133ggC8EbccETxxVM1hUWyYIBN5Cj42/hjCwszKZHltSxy8VcC4a91A== 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=afNpNfmsjxvG4peGmUE17YaoV7zG8Y17b/bMQgHwEpw=; b=ThbhaNO+eNwPQP3FgaqLWzcsiTUyf4TWaPF27vPmUTpglMTPAmBbadZJGlKDkC3s0G9tIMZj4rtaZxxMCEv75hrpUaKgpVznQmSRn0R+N7UegY3pQo0Nu1ALX+CBjeWEWokTQuEGynWxAmMGUn6q3xuPG3nBDK6TepYqUm/7/Og= 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:02:21 +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:02:21 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "Zhang, Roy Fan" , "'dev@dpdk.org'" , "De Lara Guarch, Pablo" , 'Thomas Monjalon' , "Doherty, Declan" CC: 'Anoob Joseph' , Jerin Jacob , Hemant Agrawal Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4LqyJkewM9NkuUWAfAmrqx1acbUiZggAAsN4CAAtsIgIAAT02AgAYXC5CAAbSDgIABbRGggAaWxgCAAPjG4IABs/OAgAuzNYCAAoY34IAE8G8AgAAH4mCAAbN9gIADA/pwgAZJhgCAAr+oMIAAcucAgAMT0cCAA9M0gIAAye6AgAHSrWA= Date: Tue, 15 Oct 2019 15:02:20 +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> <2601191342CEEE43887BDE71AB97725801A8C67CF4@IRSMSX104.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C67CF4@IRSMSX104.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: 5d0d6719-e6a0-44ed-1271-08d75180ade6 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VE1PR04MB6704:|VE1PR04MB6704: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; 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)(54906003)(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: Xo2lbhE1cCqHf6iMGT6uJ9hETUo24fIuN9Jw7uoxjAebzsnizg8yHi2fZbULP7/wTg4qtxrEYLtsQ24EFMvB1Z4TPDEoi6T4/jAbo9ppFFsLYTQovxdiiUS9gN9fl+xgHGHChSoq0YXDRuWACAsAv3OAd0AgLMTlZqruK/c6vxNM5iVM8iGsjb6Nl8KwKu5zkRbk3wo1G048AeVZNH0SgLbO1niVr81g4WXkKMluBQKghfysLj2is8XmfZSxLfzVyOJvTsZsLVmi1VcfuVLar0ZlNtkXOFVOfhCJf5zDS5hxO1Ch/U76jb3i8lPxK0FDbZjIZ4tGDrJtO1TLNiy8fYuoA4TTgsAt0zh/TcduHIUc0NgWum7JhXQSxeEiC8Y9hJw/sYW90CFbVLps3KV1v41lTmIoKne5O1rVJ55/8a0= 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: 5d0d6719-e6a0-44ed-1271-08d75180ade6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 15:02:20.9815 (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: x6QMJ6NO4gKGQLU5zn3GSTUp0qevanurOn5gKf424mkBsatxHcFedQDO///w6dTnHOVtLVWAe4dWS9LEFIsSfQ== 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" >=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 sen= se, as > > > > 1. rte_security contains inline crypto and lookaside crypto action type= already, > adding cpu_crypto action type is reasonable. > > 2. rte_security contains the security features may not supported by all= 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 i= nline > 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 com= paring its > output against DPDK crypto perf app output. > > 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_burst / dequeue_burst for example), this does no= t fit > in cryptodev's principle. > > 6. placing CPU synchronous crypto API in cryptodev confuses the user, a= s: > > - 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 have= 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 AP= I 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 designed dedicated to accelerate the crypt= o > processing. > > > > To me cryptodev is the one CPU synchronous crypto API should not go int= o, > rte_security is. >=20 > 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 new > 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-c= rypto > specific API? I have raised this concern in the weekly status meeting as well. But it loo= ks like nobody is interested.