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 5860AA04B6; Tue, 22 Sep 2020 14:52:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 18F2B1D6F5; Tue, 22 Sep 2020 14:52:54 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) by dpdk.org (Postfix) with ESMTP id 8D8E41D6EA for ; Tue, 22 Sep 2020 14:52:52 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KuFMRS3npPOGv07TC2/3+DD5iKCA1oKWlORejDU4PAPs75pMoIA4IVfYCi3uNQReHExTzjktOovLgy+1VWGhx9SsuceL66zxht8jWBpiFW59AD22E87FI4pS7tV/yX/f0q3L2jl3wbZ9hOwle8Zd+8+KIrpyeALaVHiWiGZpiuYz6jF9RevAqMMRXs7orBeAFFZCDkPgH0lHh44JnPwXwVK8lJC63TUstgEaRVmhIOdZiYw25bIGe1EkKnpRL/I6vnRQXaO6amv0Iofhg/PHEeTrjKENWZJgOuk8JigJt/uwZt5yKhxKsrjTsEK6l1UEABM3pbxoabYYnuLW1TTBBA== 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=hQTV4PwT4COhNeTsrOWrV0jyxSLbCjIVTaIqTmO6kyo=; b=Q5+lWIIp6LeKqOdJ/FtcUvEbvprMw1jh1sleulnR7xZDya5MePJWXFciVHA/wOZQqHjt118mbTWICco2CGlR3fLa2MglSyohfQxO6T9hgAyufN5fo0dVyI46nXtC0zdy6QcF4kyycvLb1eYUN5Qs1EAp1fD6fU8cRnLEPiE7gXpo1AOObzaTtok2g1JJKYCIfaVcAAloar6s2oM2Rt5pcbRTeyS4cXwaRlCT8lhtpIhUJV79vNVMpnujKU1d0N/AEapF79qz8oC2rTBGMQ8povii7bJQSb3ThKBIS2jqpPb8svjS4hk53OsV57FGc9YZCEW815yCO3rtsgi2T7QmdQ== 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=hQTV4PwT4COhNeTsrOWrV0jyxSLbCjIVTaIqTmO6kyo=; b=HEJZ9Wd/6eKEbqrtemz2cCdITcbExy5oc8vRFk3BbvwOxsjA8P5Fyk8rbuTMSPUAhmtvJL9RCJN2dubPeT3O40spM9Mgu9ezrM3+ZoSEuIdY4i3SBYRMd1Cl47xAE8WdUisJvpGpNzjXtL30HDtA0ltD5KZj1iAtnJypPOB+o9g= Received: from VI1PR04MB3168.eurprd04.prod.outlook.com (2603:10a6:802:6::10) by VI1PR04MB6000.eurprd04.prod.outlook.com (2603:10a6:803:d3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Tue, 22 Sep 2020 12:52:50 +0000 Received: from VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::9513:3b55:931f:216e]) by VI1PR04MB3168.eurprd04.prod.outlook.com ([fe80::9513:3b55:931f:216e%4]) with mapi id 15.20.3391.026; Tue, 22 Sep 2020 12:52:50 +0000 From: Akhil Goyal To: "Zhang, Roy Fan" , "Ananyev, Konstantin" , "dev@dpdk.org" , Thomas Monjalon CC: "Trahe, Fiona" , "Kusztal, ArkadiuszX" , "Dybkowski, AdamX" , "Bronowski, PiotrX" , Anoob Joseph Thread-Topic: [dpdk-dev v9 1/4] cryptodev: add crypto data-path service APIs Thread-Index: AQHWhbwSwlDH+pOJNkGpff/lHViImKlu7BjQgAQPvYCAAAr4EIAASSIAgAAA7CCAARZzAIAAB5kAgAAB7SCAAAktAIAADdcAgAAqd4CAAABXoA== Date: Tue, 22 Sep 2020 12:52:49 +0000 Message-ID: References: <20200904152539.20608-1-roy.fan.zhang@intel.com> <20200908084253.81022-1-roy.fan.zhang@intel.com> <20200908084253.81022-2-roy.fan.zhang@intel.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [122.162.67.38] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 70eb4142-bb2e-4f24-9896-08d85ef669e6 x-ms-traffictypediagnostic: VI1PR04MB6000: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2kEWif2LNNyWp2LxIglJGQ6LwqEmLrhLTGEQIVY7wG3NDkFw6YPYPEN7MjSLQtEbNhvtA8USIoznTPRZI/MBIJ88A6JlJjPBW2PI68zIz6bNEKd/DNLBSPm7uMK8QkTAlojlojsYinaUWqXY5EE4TXyTsL7Ou7wkZolI6GCaY/XYfhT60ZOocqMbsGuQBNuR+U5FpPtDZLxuKf6U3zr0PqSO4Wp71SWdmVxLrhPCWWnX3/MhYzFy+NbDPNdyWJeKWk5aij8uXEfucRyIK8fpCwpzxByQHKzFUsfahEpezXMLm2Q9bSepQkWCBzIr2DwH x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB3168.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(86362001)(8676002)(4326008)(44832011)(2906002)(5660300002)(8936002)(26005)(9686003)(33656002)(498600001)(186003)(66476007)(7696005)(71200400001)(6506007)(53546011)(110136005)(83380400001)(64756008)(66946007)(66446008)(54906003)(52536014)(55016002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +BVXGwzZbu5NxaynydcEO6nZi6G5HtOVTV9q9ed0awCrD1KuAJl2FZ4P01D3VSXXxnbl3fyoOxKy0g9Hlp8Nv7aKpCm2I9KDDh+3QBDf6ZLENDxRwR26luUgjfFAM0SoImKzICEB2yZ1E8WAgEC8mYkvA9EUKRrQ5lyQyT+l14USd/04vo7aeuPhSb1ro6S8WrW0eYmZawXbUVJ9+2ghm/rYkfYP1snpcU8zSbX4DSD8M3Gt3bxj/7h2mY5s8/MjxNTGq73ccaS4JKjdnWQaZMssHZPqJQSSiIC0dT1aW1mqB1ONhAc+77m5ljhYZQL7GmFeNiNn18+FyN5uOhNQCUg1l7ARWofY4TVB7xvssQqu8IVFB1DP7dTJ7TwOsaXkvSTpVZOJgnJoPqj9/iTT6hMRFJCrlH+KJA6EOj8bk1a32SsXmRnWL394vUcSaKzsCh5vzfGDP+s+RD6i5U3VT6g6k+ZK9e2SxhWA7lCje734IfTm+tiPP6tQ+EShqPza7zjbqMQYi2dvL6EzazuNyrNMF6zGv/tBjINvWWu6gSqSUiY+M/X3LDYgQEWQsMXORtpIaYsIyidHVgRvlzQa/RCfGxhVqyIc6+yGOPaLYBCcOPD6ATWoMr9pTqRhGwTQtWTNkAgRrhM23Qeo4eymdw== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB3168.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70eb4142-bb2e-4f24-9896-08d85ef669e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 12:52:50.3091 (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: 9ptom28GKBYqNsuDRvA+C8td5/cyVG2gve2hRP0N+7pkbKhcpXXhcxwLWFwUzFsPzHFBrkq3s41B0SI/jw8n1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB6000 Subject: Re: [dpdk-dev] [dpdk-dev v9 1/4] cryptodev: add crypto data-path service APIs 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, > Hi Akhil, >=20 > Konstantin and I had an off-line discussion. Is this structure ok for you= ? >=20 > /** > * Crypto virtual and IOVA address descriptor. Used to describe cryptogra= phic > * data without The comment is incomplete, however the structure is fine. > * > */ > struct rte_crypto_va_iova_ptr { > void *va; > rte_iova_t *iova; > }; >=20 > /** > * Raw data operation descriptor. > * Supposed to be used with synchronous CPU crypto API call or asynchrono= us > * RAW data path API call. > */ > struct rte_crypto_sym_vec { > /** array of SGL vectors */ > struct rte_crypto_sgl *sgl; > /** array of pointers to cipher IV */ > struct rte_crypto_va_iova_ptr *iv; > /** array of pointers to digest */ > struct rte_crypto_va_iova_ptr *digest; >=20 > __extension__ > union { > /** array of pointers to auth IV, used for chain operation */ > struct rte_crypto_va_iova_ptr *auth_iv; > /** array of pointers to AAD, used for AEAD operation */ > struct rte_crypto_va_iova_ptr *aad; > }; >=20 > /** > * array of statuses for each operation: > * - 0 on success > * - errno on error > */ > int32_t *status; > /** number of operations to perform */ > uint32_t num; > }; >=20 > Regards, > Fan >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Tuesday, September 22, 2020 11:18 AM > > To: Zhang, Roy Fan ; Akhil Goyal > > ; dev@dpdk.org; Thomas Monjalon > > > > Cc: Trahe, Fiona ; Kusztal, ArkadiuszX > > ; Dybkowski, AdamX > > ; Bronowski, PiotrX > > ; Anoob Joseph > > Subject: RE: [dpdk-dev v9 1/4] cryptodev: add crypto data-path service = APIs > > > > > > > > > > > > Hi Akhil and Konstantin, > > > > > > > -----Original Message----- > > > > From: Akhil Goyal > > > > Sent: Tuesday, September 22, 2020 10:06 AM > > > > To: Ananyev, Konstantin ; Zhang, Roy > > Fan > > > > ; dev@dpdk.org; Thomas Monjalon > > > > > > > > Cc: Trahe, Fiona ; Kusztal, ArkadiuszX > > > > ; Dybkowski, AdamX > > > > ; Bronowski, PiotrX > > > > ; Anoob Joseph > > > > Subject: RE: [dpdk-dev v9 1/4] cryptodev: add crypto data-path serv= ice > > APIs > > > > > > > > Hi Konstantin, > > > > > Hi lads, > > > > > > > > > > > > > > > > > Hi Akhil, > > > > > > > > > > > > Thanks again for the review! > > > > > > To summarize, the following places to be changed for v10. > > > > > > > > > > > > 1. Documentation update and reviewed internally in Intel first. > > > > > > 2. Add the missing comments to the structure. > > > > > > 3. Change the name "dp_service" to "raw_dp" to all APIs and > > > > documentation. > > > > > > 4. Change the structure > > > > > > struct rte_crypto_sym_vec { > > > > > > /** array of SGL vectors */ > > > > > > struct rte_crypto_sgl *sgl; > > > > > > > > > > > > union { > > > > > > /** Supposed to be used with CPU crypto API call. */ > > > > > > struct { > > > > > > /** array of pointers to IV */ > > > > > > void **iv; > > > > > > /** array of pointers to AAD */ > > > > > > void **aad; > > > > > > /** array of pointers to digest */ > > > > > > void **digest; > > > > > > } cpu_crypto; > > > > > > /** Supposed to be used with HW raw crypto API call. > */ > > > > > > struct { > > > > > > /** array of pointers to cipher IV */ > > > > > > void **cipher_iv_ptr; > > > > > > /** array of IOVA addresses to cipher IV */ > > > > > > rte_iova_t *cipher_iv_iova; > > > > > > /** array of pointers to auth IV */ > > > > > > void **auth_iv_ptr; > > > > > > /** array of IOVA addresses to auth IV */ > > > > > > rte_iova_t *auth_iv_iova; > > > > > > /** array of pointers to digest */ > > > > > > void **digest_ptr; > > > > > > /** array of IOVA addresses to digest */ > > > > > > rte_iova_t *digest_iova; > > > > > > } hw_chain; > > > > > > /** Supposed to be used with HW raw crypto API call. > */ > > > > > > struct { > > > > > > /** array of pointers to AEAD IV */ > > > > > > void **iv_ptr; > > > > > > /** array of IOVA addresses to AEAD IV */ > > > > > > rte_iova_t *iv_iova; > > > > > > /** array of pointers to AAD */ > > > > > > void **aad_ptr; > > > > > > /** array of IOVA addresses to AAD */ > > > > > > rte_iova_t *aad_iova; > > > > > > /** array of pointers to digest */ > > > > > > void **digest_ptr; > > > > > > /** array of IOVA addresses to digest */ > > > > > > rte_iova_t *digest_iova; > > > > > > } hw_aead; > > > > > > }; > > > > > > > > > > > > /** > > > > > > * array of statuses for each operation: > > > > > > * - 0 on success > > > > > > * - errno on error > > > > > > */ > > > > > > int32_t *status; > > > > > > /** number of operations to perform */ > > > > > > uint32_t num; > > > > > > }; > > > > > > > > > > > > > > > As I understand you just need to add pointers to iova[] for iv, a= ad and > > > > digest, > > > > > correct? > > > > > If so, why not simply: > > > > > > > > > > struct rte_va_iova_ptr { > > > > > void *va; > > > > > rte_iova_t *iova; > > > > > }; > > > > > > > > > > struct rte_crypto_sym_vec { > > > > > /** array of SGL vectors */ > > > > > struct rte_crypto_sgl *sgl; > > > > > /** array of pointers to IV */ > > > > > struct rte_va_iova_ptr iv; > > > > > > We will need 2 IV here, one for cipher and one for auth (GMAC for > > example). > > > > Hmm, why do we need to different IVs for GMAC? > > And if so how does it work now with either rte_crypto_op or with > > rte_crypto_sym_vec? > > > > > > > > > > /** array of pointers to AAD */ > > > > > struct rte_va_iova_ptr aad; > > > > > /** array of pointers to digest */ > > > > > struct rte_va_iova_ptr digest; > > > > > /** > > > > > * array of statuses for each operation: > > > > > * - 0 on success > > > > > * - errno on error > > > > > */ > > > > > int32_t *status; > > > > > /** number of operations to perform */ > > > > > uint32_t num; > > > > > }; > > > > > > > > > > BTW, it would be both ABI and API breakage, > > > > > though all functions using this struct are marked as experimental= , > > > > > plus it is an LTS release, so it seems to be ok. > > > > > Though I think it needs to be flagged in RN. > > > > > > > > This is a good suggestion. This will make some changes in the cpu-c= rypto > > > > support as well > > > > And should be a separate patch. > > > > We can take the API and ABI breakage in this release. That is not a= n issue. > > > > > > > > > > > > > > > > > > Another option obviously - introduce completely new structure for= it > > > > > and leave existing one unaffected. > > > > > > > > > This will create some duplicate code. Would not prefer that. > > > > > > > > > > > > > > > > 5. Remove enum rte_crypto_dp_service, let the PMDs using the > > session > > > > private > > > > > data to decide function handler. > > > > > > 6. Remove is_update parameter. > > > > > > > > > > > > The main point that is uncertain is the existance of "submit_si= ngle". > > > > > > I am ok to remove "submit_single" function. In VPP we can use > > > > > rte_cryptodev_dp_sym_submit_vec() with vec.num=3D1 each time to > > avoid > > > > > > double looping. > > > > > > But we have to put the rte_cryptodev_dp_sym_submit_vec() as an > > inline > > > > > function - this will cause the API not traced in version map. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > Regards, > > > > > > Fan > > > > > >