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 69B77A04AB; Wed, 6 Nov 2019 13:22:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8900B1C134; Wed, 6 Nov 2019 13:22:07 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50045.outbound.protection.outlook.com [40.107.5.45]) by dpdk.org (Postfix) with ESMTP id 0FEE41C131; Wed, 6 Nov 2019 13:22:06 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mz7sKkwPGikhzbb0ZRpEoX5ytx5NIAvkOGJhXy1GfbkEaZd31iKa1SGq+y7aGth4t10JL/l2G8paktypg+/+6dXcl9psBIbCClyNtlXhZdep/oZtCQV8N8eqiUCVFn0ZYbmzKR4zpNP/XqyeL+AW8cuXQGWiBWrJzSl9TtYUq/iBL7u5tXQ75YXuWKmA64j6sWZTwHSGPW7krOwUSZeGMSpNTwdsaFCthsjLkudEMC9F2ZcOERQmQ3cdXZgHBXE+lB6XlVozVFk70JjDglWnR5cIUWQe1U9u7hExsU0g6Y1ArIVaaO8zoPm3ZQh8OjwVoRm3gEq5c+1MBwN4C4gMDQ== 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=BgTieHFLEW+roGM5HzQgEeYodHPJwZUdhb+clA04Vzc=; b=TvnFWq6PczdlFQxyQeadY3ASha2Io84oc6wmYgDuPKuKCAwmHzjZfs0SlWzc4JAIv+B7VQzjmJ0q+PftJCZHG0froE0UwyhP5ejrxRWWZ2bMNCyQcNdzTtYfpyiSTmj4jCyliu3I76V7d0hSFrOB6aUePaMfLhg13iYvpiazPEAwL9UahVN8ZBlZAPzHdznsN+fOxCcsmcF78dmDxV19NQ+CkK4b1aazzM9xjTSnnj1Ly30QXHaEiazHPVhoyqPDd2n0bLURaqzYvj3pafC4YuWq2tCwxNOwmMEUuHKcXZ5TeSOR46Q7P5l3tAseOiHAiTke0soczmg1mRNy7YDpKA== 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=BgTieHFLEW+roGM5HzQgEeYodHPJwZUdhb+clA04Vzc=; b=CPp/ZjN6ijW0eBB8azjoOfMNOm5rLXJBzdIzDWpQ1HO0HzG9tSp8+IbFfff57zIll1+S9r+NLXsMDzt7ThfG10GHznRPaoY9bIfkGdfO1QRhbsKxxi9rcALCWTYtCS6yXOHbkEriwLNC6iYa/NiTtxrdeZKPjH8r275mViNTTXo= Received: from VI1PR0401MB2541.eurprd04.prod.outlook.com (10.168.62.139) by VI1PR0401MB2688.eurprd04.prod.outlook.com (10.168.66.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Wed, 6 Nov 2019 12:22:04 +0000 Received: from VI1PR0401MB2541.eurprd04.prod.outlook.com ([fe80::7012:936f:53fb:f7b6]) by VI1PR0401MB2541.eurprd04.prod.outlook.com ([fe80::7012:936f:53fb:f7b6%5]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 12:22:04 +0000 From: Hemant Agrawal To: Thomas Monjalon , "Ananyev, Konstantin" CC: "techboard@dpdk.org" , Honnappa Nagarahalli , "dev@dpdk.org" , "Zhang, Roy Fan" , "Doherty, Declan" , Akhil Goyal , nd Thread-Topic: [dpdk-dev] [dpdk-techboard] [RFC 0/4] cpu-crypto API choices Thread-Index: AQHVlIdQ7oq/MDeXc0Sd587zl9qrY6d97NaAgAAWMYCAAAycgIAAACxw Date: Wed, 6 Nov 2019 12:22:04 +0000 Message-ID: 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-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hemant.agrawal@nxp.com; x-originating-ip: [92.120.1.69] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 849b851e-7949-4ddd-c1ed-08d762b3ef42 x-ms-traffictypediagnostic: VI1PR0401MB2688:|VI1PR0401MB2688: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(199004)(189003)(54906003)(110136005)(4326008)(14454004)(486006)(476003)(9686003)(44832011)(66066001)(66946007)(76116006)(5660300002)(55016002)(74316002)(66556008)(66446008)(64756008)(25786009)(446003)(3846002)(7736002)(305945005)(6116002)(6436002)(229853002)(11346002)(66476007)(478600001)(316002)(14444005)(256004)(52536014)(2906002)(102836004)(81166006)(81156014)(8676002)(26005)(7696005)(76176011)(99286004)(71200400001)(71190400001)(6506007)(186003)(8936002)(86362001)(6246003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2688; H:VI1PR0401MB2541.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: TWma7jn21apGZy9+wmdb7CjXVV02u+XkEyBSKQ5oqzxI6gHPsXsRJRA63YskARc4ohVLwBbZ1PKQCg2qPgbbivoRMcyiYrf+bjN3ZwX23+k6HEUpLFUGsB7aHfi5eFWNRJyNoZpP5jnp/s2pQ622jTaidMZGe3EjaTJ83LlDCMQC1tvSmsUF7D54VWX84LO3AN0AhShhMLo0Vp/w2XB/fFu7NspIJeP74p0vZIGt4h15ORZWtePp3B7mnmL0jxLXpuXzJX4BYxv6zyhlIA+MzOfhsYbBIDdBXW/yLO26zr+5wiVAhpA4lYkMFfnmCqoPvj4aXPQCH1h5z8NhsUnJDxF5EBl68ryFKf85nA9Zd2mxKd1qeztf0iIfLHB3Oc3egnwPjPyZcb+nelPn9IqWPaINrOpYY4D89OnAJmLbKZOj/l5vKW9egItzpsL7w2oS 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: 849b851e-7949-4ddd-c1ed-08d762b3ef42 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 12:22:04.6923 (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: X/HvDORrShuHEp3O3SLXe+Hn5KI59mKs52wiGem+fLFg0eCnkZoNQ7j9OhRpkQx4FmohFB4qac47M+KD2nInMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2688 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" > 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 penalty to SW PMDs that > > > > > > > have to "simulate" HW async behavior (crypto-ops > > > > > > > enqueue/dequeue, HW addresses computations, > storing/dereferencing user provided data (mbuf) for each crypto-op, etc). > > > > > > > > > > > > > > The aim is to introduce a new optional API for SW > > > > > > > crypto-devices 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 > > > > > > > functionality, there seems to be no agreement on what would b= e > the best API for that. > > > > > > > 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 > > > > > > > API > > > > > > > > > > > > > > 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 > > > > > > > that will help to understand pros and cons of each one. > > > > > > > > > > > > > > Akhil strongly supports #3, AFAIK mainly because it allows > > > > > > > PMDs to reuse existing API and minimize API level changes. > > > > > > > > > > > > IMO, from application perspective, it should not matter who > > > > > > (CPU 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 > symmetric/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 initializat= ion > 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/queue structure) can be stored inside the session itself. > > Though I really doubt any lookaside PMD would be interested in such > mode. [Hemant] Lookaside PMDs may be interested but may not be in synchronous nat= ure, but for raw buffers processing. e.g. I see a use-case to support crypto without forcing to use crypto_ops o= r mbufs i.e. use plain buffers. So, I want to take advantage of similar APIs, just extend an option to show= that it is async in process. And then overload existing or add an API to get new such raw crypto process= API.