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 EA73BA04B0; Tue, 22 Sep 2020 14:15:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8D6751DB5D; Tue, 22 Sep 2020 14:15:33 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 828451DB57 for ; Tue, 22 Sep 2020 14:15:31 +0200 (CEST) IronPort-SDR: DFpoouETAygJRJfhmgxRPtwRKUTtmKmVK8iHEIs42i1lj8gykEvy465lkeCJSUjVM6ttILJbJV ONDx0jqgQ0kg== X-IronPort-AV: E=McAfee;i="6000,8403,9751"; a="159878175" X-IronPort-AV: E=Sophos;i="5.77,290,1596524400"; d="scan'208";a="159878175" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 05:15:30 -0700 IronPort-SDR: yYoElnB9r6ZXLGVmF0URFxQLuIoOn8BYOyYbp6osWhA1Rq9NuPPStkPgSD8XUUX10d+GiDek2h 62RtQyPpg27Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,290,1596524400"; d="scan'208";a="338276172" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga008.jf.intel.com with ESMTP; 22 Sep 2020 05:15:30 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 22 Sep 2020 05:15:30 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 22 Sep 2020 05:15:30 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.58) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 22 Sep 2020 05:15:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E4CjJ9wN7HQ4XQSCX1ekey8V9+DylgfQeYcdqaVDUMyJP6lNxcLee0d0lirsZZaRgGRBtLskhGkRw0YY7/Y0CIRFE9FCcYpDQOGiOW7ghYv5xSRytjvTDt81dlKnIfT30ZXR1QooXoxbyrjSicjhxmaVkGqzywNeVB7d+Yo7PjUEUz44JOf+cV725JrmldLia3uoIVeaHJb5vVvadhpfw6wOcTSzXZIBnD3MzBvScOzHnwoy1B57KMKxuxHdW5eDuYcHATL5Dtv0dcOhdpsqh58I2fR88M8QskfgK1YNm15HuYJu+n3dpdUvTw7XQBx3bTQiUxxJsmyQGOTWWXyzeg== 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=6/SmqYB86MIMjy6CgY0IgcPfiCyE5HWK7jvfkUCKXhg=; b=KQrJt9JqCaQNSiaXgu+sQSbHXWW3Qeiqy/AXevJzbrcOGJfJKt/lDDRQIOH6cL083B4sYyewytiF5MxPKrCD35nI9w0kx2spKsUaJYvVfEmLM5sxx/99vIpgPSH1hrMsEDq59SHf3DKxP473H9JUCsRPRHdNR44PXktjqrbanbDXgkA2AopZ1l+m044fJMmdnxugcvaM2CTNLkmeuGgg/lISQuRauKv5Ak/xF+SSd5YEuLuz+2xycuohl6Exgj9dcboqxESo0FRlEWjRNAevdxa6m6582cyaj1Ytz5umU/bd5ZoCZGaCPobhlDmWfcDwPM+ocKs3Of1j2XC4FEmN4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6/SmqYB86MIMjy6CgY0IgcPfiCyE5HWK7jvfkUCKXhg=; b=yK0gmZhzQSXiqvU9tvxRfTQnLGSbEttEBHIc+8vgW6rm9IPZyS/kNGoH1m0GpMlGZb2mrs/Us/1GC3yRTluGOdxK2KstpZaE5Pubwt+wVV5Ined8x5xWrKK5cjylCZJUGRzxvIToQsGU3YNPpk2k/HFiy98c9legBh4sIBlxtuo= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by MN2PR11MB4206.namprd11.prod.outlook.com (2603:10b6:208:188::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Tue, 22 Sep 2020 12:15:28 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239%5]) with mapi id 15.20.3391.027; Tue, 22 Sep 2020 12:15:28 +0000 From: "Zhang, Roy Fan" To: "Ananyev, Konstantin" , Akhil Goyal , "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: AQHWhbwaRQXVNw2ngE+5SqoPhUuyBqlu/9oAgAP1tgCAABxYAIAAPMewgAADYYCAARKlYIAACjIAgAAEsICAAAV7wIAADsYAgAAe3xA= Date: Tue, 22 Sep 2020 12:15:28 +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: zh-Hans-HK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [95.44.220.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a0bf7f0-93eb-4970-914e-08d85ef131cf x-ms-traffictypediagnostic: MN2PR11MB4206: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v1u6g8z5dIa8YyZptQjjzBEWtguXPnH4UMVgpDFGlBiwtzkgxsNccKo+Mmkyl6JFsCKkqnXuGaYPHWexfZDj+b+6DCs55tHUupWEoHLbx2dezmrkoKfS9vpnbHLRaW1fZOEUd5Lp/05BD1NSwJbwuxXMzWYplfY9U1PT0EgrIA+Z6ddz18Uhjeuj1tAPWPnWbfCxMw1FstaKePnW6pgQUV8xdn5HDy67WIVokWaikKl0f9pC7G7oZVEHbs67rMnkDxdQnSimERp5jeIDBs/sHJ3Ca1ZGtyRf8PfR1UUXsP7TA8eSnwZZ76jozWvV7RkF x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(86362001)(71200400001)(33656002)(478600001)(66556008)(6506007)(66476007)(186003)(53546011)(66946007)(52536014)(2906002)(7696005)(76116006)(54906003)(9686003)(55016002)(110136005)(64756008)(66446008)(5660300002)(316002)(4326008)(83380400001)(8936002)(26005)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TzvQ8w8b/2+vfFeucP5PjWAvbnq3NzFY51ygRpoAz1hMOR52sy3dBF5yHIilDOIPvNNWHC7iFG8T0WsCnvDh3qUrq/O8Hh1qU0lXR3NSXMGXIxkajSsnaqe3X1xjNqd9TCqlFuGOihK4mB6adSyMYJXLBX3btDj2wrYEboXZ8vU/iT/w6SiYkG6dXtE0Th8CGc74fnMW5VfPdbCXOezYcSuCeG0bJlfeAqBHdixRJGnHA+KvNmR8+fStW7ItHmFRvK7Uybwr8nMyAxxkHN0c7L085d1tLPIGw2tra90up3hviBduRBPZ5V9/bLX06NjQGFBuLE8c2dFjb9Po80GmH72wnYfvWBv3C9IYYHqBXuwiNdcfP73zrsZn6xZ6glVI1Q9CnzUrQK4QFpinT2ACttI/vO+5mfWs1OWBqKmX95sdfT9SkFDzwCSlHeymgQO7Thf0QGEeyXldtSecX+vWq90lrcrMjRmZSOSOeZaQNne8Q7RHknWJtscLpeTOsVMdYu7R1xSf8KE6ItB+OD0oG40abD+0cBu90VE4wz9BLzmdIV7VdVbw7HxTt9GDBmvVzGQlO+XCD7qDHT3JEP5i2+qAg6MLpZRTOFZW51F5DIroDNehz13nCGlV62ewVpkC0aPYWlLuzrBGb3SrnqQOlg== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a0bf7f0-93eb-4970-914e-08d85ef131cf X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 12:15:28.5732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P1sKhNjViUlK143XrUjcAyhJ1A3xyGBfv3TFS8GRQXYJAAJJ6scndXYvijcJXznC7lpxhb2DklGihSdtPWmzCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4206 X-OriginatorOrg: intel.com 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 Konstantin, > -----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 AP= Is >=20 >=20 >=20 > > > > 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 servic= e > 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, aad= 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). >=20 > 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? >=20 Not only GMAC, the wireless chain algos such as SNOW3G requires IV in auth = field (test_snow3g_cipher_auth() in unit test). Rte_crypto_sym_op has auth_iv.offset to indicate where the iv is stored in = crypto op, so the virtual and physical addresses of it can be deducted thro= ugh the offset, but not yet for 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-cry= pto > > > support as well > > > And should be a separate patch. > > > We can take the API and ABI breakage in this release. That is not an = issue. > > > > > > > > > > > > > > Another option obviously - introduce completely new structure for i= t > > > > 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_sing= le". > > > > > 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 > > > > >