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 1972AA04B6; Tue, 22 Sep 2020 14:50:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0AF7E1D6A9; Tue, 22 Sep 2020 14:50:10 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id A30C21D686 for ; Tue, 22 Sep 2020 14:50:08 +0200 (CEST) IronPort-SDR: 5s8J0wAjlXS29ReTAxAtpj8dEnSwcWVX2AcWhLkq/bwJKFZCCpuX4ZfxJ0vuKZ/yRRuFhU3vQ8 pW4xNkp55aNg== X-IronPort-AV: E=McAfee;i="6000,8403,9751"; a="148342666" X-IronPort-AV: E=Sophos;i="5.77,290,1596524400"; d="scan'208";a="148342666" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 05:50:07 -0700 IronPort-SDR: Tk+n1m4OHIWGSqHIwPDn/dbFcT/2Ml2t44W5bCMeWqTKx8PZPVkOOEWusK9QVIPddjp7vHHZ1R m2Gt+utztpTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,290,1596524400"; d="scan'208";a="334995192" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga004.fm.intel.com with ESMTP; 22 Sep 2020 05:50:07 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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:50:06 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx608.amr.corp.intel.com (10.18.126.88) 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:50:06 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx602.amr.corp.intel.com (10.18.126.82) 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:50:06 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.55) by edgegateway.intel.com (192.55.55.70) 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:50:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YEB5hZiiBO65fSJxi7QMorh9+bjGO98UwzJvl3TMd4SJQJHc6FJNM2noPP94Q9PJoWOPxJ6jKJ9mM9jSz2PcJcWXt7X7p3VLwJC6gS7KSYgzGJVnX8r7ZvIJ5H5G5B1Qdco5nbFXMgcTqTa2tjLSj4Zm4d54+G2mlaFmm9zfPVJ3Up9vRaNQBibw/cgziiZozpu/wOyWsqBn2f7+v4+iv/jRwCzZ3hOsEXOI/d5hPVgwBHX1MrxbcSN6toosRX4i8tHDEUAkNd8ZxAwJ6oWs4YvCikmgPRl2AKMgipxWc7QiFeQPkWCCwwPg3IG+A8wfpuQj4bI3hFaF2lUA380Xbw== 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=zhQ9cA1oT5aOvgmWmZ5D1/Yziw7/9vvlvkctwb0sgIQ=; b=STlN0agUFvVmY6M7vbJCfBPgUQxH7xu91D95fdMHVva2xq1BDNtjA6OQvr256csNKmXN1fak1RQPQmHflJpZj9Ts+2JQ3aLd5LxGu1oCFMdhC+fqLVkXyM8wmI1wKS3LxyzfWBRb3oAOf/+61ENRvl+YYQjaDKrNJhMtB0OZPnutjXjWLe5szSpzMbDDeDAEaRxjGWmrKz0EigPlmEvD7HJ3skguEg5c/jx4ulrItBb/ezfhcTFsDSie93ARlgaixe0Q0QQhq5ZH/yu0pRXsQGUPvf8l2d+0NlPGsgO71Ctwi1Abc9nCNETi56WBR1m3vTWghEowgD4xYUfX9oMDcA== 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=zhQ9cA1oT5aOvgmWmZ5D1/Yziw7/9vvlvkctwb0sgIQ=; b=kUHlhq0dsgVhzVwzlNmh7IZKhdDbMyFxOXu9/aJZZfsUmDjS8pyWAnIB3PbWmzncAZmUCez3HRTJT45SV/BlbXkNUrspnyOsbOu1RL6lJRRH2PZZVMwuOPoPtxQTas0yDmAGLb/OsaoAfTUN6Y3NHMhIegrV3gNiDNU2JYO8IqM= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by MN2PR11MB4647.namprd11.prod.outlook.com (2603:10b6:208:262::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Tue, 22 Sep 2020 12:50:03 +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:50:03 +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/9oAgAP1tgCAABxYAIAAPMewgAADYYCAARKlYIAACjIAgAAEsICAAAV7wIAADsYAgAApP2A= Date: Tue, 22 Sep 2020 12:50:03 +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: b536a969-162a-414f-0dea-08d85ef60668 x-ms-traffictypediagnostic: MN2PR11MB4647: x-ms-exchange-transport-forked: True 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: 63pIwRfHbiJQOfshKsOCFavTIpa6v+cuuRN9FJivieRni6QNef8CubwB/isrmRV42jUH6G+SfH40eQUGuNX8p82piSn4enSfBGNYdX8lzpn97AirzJHpTSDQ1hgWkntTZL02e6FcKcX9N1LV5tgXSDgXWhDjsDGUahJ0oC5LiysbRY1XxRauPxIVxJkDFutClUnJrUmlrvhNOZ7aeR+njB/8ubrZ7IQshvDfJ+um+aAbz7Ron5pnT7oChPTopUIv0xRCSpQQLVCvmMeR+xrJXI2tD2RmttoBoxJtAN+S8LPJ7wvIhGKkBUdoR3hr7qUgRVDDdijVOE1ruLrrdBezR+fdrP4DbZgSG5NobXmlJD8EMIa3bwX7Euj/omXzRXqT 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)(136003)(39860400002)(346002)(376002)(396003)(366004)(186003)(7696005)(66946007)(5660300002)(66446008)(76116006)(64756008)(33656002)(86362001)(71200400001)(53546011)(6506007)(52536014)(55016002)(2906002)(8676002)(66476007)(9686003)(4326008)(83380400001)(478600001)(66556008)(316002)(8936002)(54906003)(110136005)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: VlA/pLRImsY5/aKhUfM0O6qKS55wJVqRYyl4XyZuC6cHvXeAPNuGghgboupS99UWFUpaX9/iaJpsfJdrPiD8ox10uHK0aknGvsI2ur474uuV1sbwF2yAQrxX9HP1wctVjPhaDoqbbKW1zz9ue6qy3sI9T0W2lAAZNlIYl9vZzSzrpbmKhzhIJ5MKQ1soO8ZDxmJOmlBFzeR+oFt+kQOnJisCinVOxkl1MRSrlSMPYfi6tOHXjoNBdTYDSa8EPczziYY1rD3gBMscPRuYuVK7h/VW3uyp7Sx62zl9QwoGTRawe6cXfWiA+e9CEDVRN1R9ges2yWx+rVIi8lLTBV0BZyBaCs8uRLSjAIgv4O00u4L+Apj5bM3ziCbfU6U8cRSC9UDFLHwZ+dWi5/N+2q/d0or0pCxkafXex5FwHiX+dsDPfgbwR8H5lbt6r7XfalAvAi+Ip/Pp0VITNMPZRTd78r1hMMguCfzk/DPvk4AF8FH25wgZQiac0HZbL/BFs4U//ZuJ0GDWOjlhd8iVLPhjoF0476t8Q0ZytqXOhgxY4AJUqrWYf3ZLJTxIhaCudKaaVqfRboe4sVBV7PMkvhM3JLYjzvKY03xkP614tQ3jPCoCkjnENPq72i1r0q5vo4ukxi+VCZ+/2Dr4XR4XfVydYA== 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: b536a969-162a-414f-0dea-08d85ef60668 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 12:50:03.1635 (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: xtOUuNmgWNoaCD8hpFI8cox90JWBf/rGzwYJknldmd0+ZybpIMkrMAtw3kan2FLEDt9nhm9YNDws4kYLOSJ0ng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4647 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 Akhil, Konstantin and I had an off-line discussion. Is this structure ok for you? /** * Crypto virtual and IOVA address descriptor. Used to describe cryptograph= ic * data without * */ struct rte_crypto_va_iova_ptr { void *va; rte_iova_t *iova; }; /** * Raw data operation descriptor. * Supposed to be used with synchronous CPU crypto API call or asynchronous * 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; __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; }; /** * array of statuses for each operation: * - 0 on success * - errno on error */ int32_t *status; /** number of operations to perform */ uint32_t num; }; Regards, Fan > -----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 > > > > > > /** 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 > > > > >