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 F0567A0527; Wed, 8 Jul 2020 17:09:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D16EE1E4C2; Wed, 8 Jul 2020 17:09:08 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id F2F6A1E4BD for ; Wed, 8 Jul 2020 17:09:06 +0200 (CEST) IronPort-SDR: 9/1JSsEwhiqROBlhtKsT8095c2zXR0I2Eh5ViMMk8UJm3lLDwepV71roHtzj7ilryIJzCYMaqF ktHJ84xtONjw== X-IronPort-AV: E=McAfee;i="6000,8403,9676"; a="232683753" X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="232683753" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2020 08:09:05 -0700 IronPort-SDR: nqVt+LvRHJW42BzKfewcriAWPTMNu0N6eKP7IbxAiSZTqcRLmpHSqh7T3nCLydOiNz7ycopyc4 EhOAZayQFJ1w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,327,1589266800"; d="scan'208";a="323908390" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga007.jf.intel.com with ESMTP; 08 Jul 2020 08:09:05 -0700 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jul 2020 08:09:05 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by ORSMSX114.amr.corp.intel.com (10.22.240.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jul 2020 08:09:05 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.168) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jul 2020 08:09:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QgfMbg7srY/MoXFJgmG0/sj1op5q44dSIa148aPihrJ0bapXp7WOT8qF5TDWXsTx9ARrYGzz0KJkkWqV3VCMKaV6n8ZzgMQbLFcJ5gtNBnRXFxTLZuF21xqOucpvrjEjUl4Aoop97Wyse8imHj5aSphxDQ/Kp1OjCOZMehNhPogFaAIrdOANKe+xWWnshfaCJ9IZVwUy5fiZ/tT0rcQahWZIrZNE/S9dFVWZ3tE0L5DfLDvSZTDB8fV1IT8CgdNspEVTH/7LQBIrddP/y1O1ZytxAW+9MY5QwX+NAMgPLa308YIWvJ1vcLFWE+FAG8LqpbYivfjodgupyhKDlxkT4g== 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=2B0/1vvLHniR7CqljtvCCEGGTNVsVIS/IFoji1jhxP8=; b=BIVSXKLFTTbKE6F0VbgWY7DLDCr7a0DqkEvOe6KcWSQGfLft/L0OOwSElVrmOt/QNNZYdHpwouRIUqmrMnbNYKC/CumlBk4ZWZDYJo7O37WVhND/DQdq3f9uuAcDg2ypusYODj2/w2Pt1v8MTkMj+A0VHn6cqOUaNIB8ZCnC5UVR+8yaigasiZXM6DHc0VfBVX9iTdgIjy0GGZvILUynfTEbdGTZzP5airVjAriOuwb6uPRaenYQSkB6etzc2QJ2cvxP6MsqCVzIupbH+8pDWwZrQEnr7VNAlZTiiW3To1rlYtlU3e2PyJkSeNqG00HE7wBL1H3RTaJOunxwblcroQ== 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=2B0/1vvLHniR7CqljtvCCEGGTNVsVIS/IFoji1jhxP8=; b=EWUOWRH1uY2qhanK0JCXiWRsp6Y1NWvFLNZZEF9UXhm5LP8uBuS0PS4v9hkbWdybto1niq9jnIJobSXJIzBt+72uMlmGu3YuFeOHV1AbIoZyJNQ/hOgZ+aAKnVrgaJROroEcxLlzovrmdwW+wZE3alVugkEWCFdE/xrdpAKWWcY= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by MN2PR11MB4269.namprd11.prod.outlook.com (2603:10b6:208:190::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Wed, 8 Jul 2020 15:09:02 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::dd8e:7a6b:53ca:2a8a]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::dd8e:7a6b:53ca:2a8a%4]) with mapi id 15.20.3174.022; Wed, 8 Jul 2020 15:09:02 +0000 From: "Zhang, Roy Fan" To: Akhil Goyal , "dev@dpdk.org" , "anoobj@marvell.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , Nagadheeraj Rottela , Michael Shamis , Ankur Dwivedi , Jay Zhou , "De Lara Guarch, Pablo" , Hemant Agrawal CC: "Trahe, Fiona" , "Bronowski, PiotrX" , "Ananyev, Konstantin" , Thomas Monjalon Thread-Topic: [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path APIs Thread-Index: AQHWUTh9W23hQCo6PkeV7n4G/Cv9Iqj3u/CAgAKPEPCAADBDgIABdgEggACpBwCAASsPsA== Date: Wed, 8 Jul 2020 15:09:02 +0000 Message-ID: References: <20200703110923.26452-1-roy.fan.zhang@intel.com> <20200703124942.29171-1-roy.fan.zhang@intel.com> <20200703124942.29171-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: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGMzZWE2NTYtZDU5OC00YjdjLTg0ZTQtZGExZmU1NDNlN2E4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieU02UzZhWGp6VCt4Y2NmZnlFV1NmZkhtTk9LRGJSdnlsVUV2SERTNXRHSkM1VlF5UzJYS2hcL3VXRitRaXFCeTgifQ== x-ctpclassification: CTP_NT dlp-version: 11.2.0.6 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.151.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0dc9b39c-4c23-4cbe-fcc7-08d82350d98e x-ms-traffictypediagnostic: MN2PR11MB4269: 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: 3c/3B2SVbKGba678UwsZFELfPmbCC/fHx821/jrLN0INrbSz1WhYLw1/TYLBJT+Row+h2nF3Bzuq4cYHQsPqxrwHnorIkY1gBm4pQQ9IScdYAKQzq1eOgVF5TqSZ2E6xJaSbBIsDRL0Dt3fzQyLDtXTSZVoyDkfjein/ighrEl48kwTqxeEUOUGVCoQcLa8W4OygrN0tVKFDv2PG2zISwtPgPms67EIJ9TeiVXS+/hrXYsUP5KbKnFBEOX3Ij0c2APE1lt2VlA4p/h75Z4KOnFbdr0OEaHaEhB51qw2JBZ//DVgrgx9nIIBNxLv4BEJ8/wgcw+XMdmflIJ90B62wBMY8HG+NEkb0pEKmtGxLRMxR0O2xb6NMWKCt86vwz4DjqZ2AgEvTcDRke+pS0hjpAej/NXZCwYUYHcjSvybxRUntfo3sb9bU/PUq+tCa3+fv 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; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(316002)(110136005)(54906003)(186003)(71200400001)(55016002)(83380400001)(478600001)(33656002)(9686003)(4326008)(53546011)(6506007)(8936002)(7416002)(7696005)(8676002)(64756008)(66446008)(52536014)(66476007)(66556008)(66946007)(2906002)(76116006)(5660300002)(86362001)(26005)(966005)(921003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2WFI7jHLJYAMzn6W5ZJoVJZseikxPfPmu65Jp8xFiDFxD3CJHw0tOpinPkurEhCfoEkU8YVWZzLxkkFFdDV7aqoBGIDfXg9+5F2Arb8zLKIDGOMIEZwpk3EJg6w8fGVaVywrJfQ9ZzUdhOebH0/57680mPyAV6XvjDKkDnW+aZ2vx9vURkue9Xs3gO1OBFnqKBy833y5I1cuZxEkgNIxHVYtrjiVJzd5MKaCqoWLiqnD0YYZvp0vS43m4t93+mrnkgUrLpyhYiBrEAkfoJOvlLmtN3tDhJ9/Hs7f3cY3kHr0RXiLIQc5aEucL1ZmTYN1qwGvwVuDYXfuRxe6dTPDfHh8Z8d9RtTD3TI3JCp6vNcDDfip77xbxV66MStHPH38QY1k/pSo8bjt4wGN5auInHdECL/lEoikLlSDXCqsbgSgwWZ7mFWRpwEwynnvhVnMBXeBR9yhwP0mTzj0vZZVnfgy0mVAbKPiVe25CIOdvp9dPnRCuU/BET5Yi/zxAp45 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: 0dc9b39c-4c23-4cbe-fcc7-08d82350d98e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 15:09:02.6098 (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: nHKjNdM39wIYAefi5fzTNbrb8LCfrpRx3OuVM0o6/BgHr9xFj9kLv7+xVl5heXXKMQ4nYAiOuPO2FR9JGE4xng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4269 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path 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, Thanks for the comments! > -----Original Message----- > From: Akhil Goyal > Sent: Tuesday, July 7, 2020 9:37 PM > To: Zhang, Roy Fan ; dev@dpdk.org; > anoobj@marvell.com; asomalap@amd.com; ruifeng.wang@arm.com; > Nagadheeraj Rottela ; Michael Shamis > ; Ankur Dwivedi ; Jay > Zhou ; De Lara Guarch, Pablo > ; Hemant Agrawal > > Cc: Trahe, Fiona ; Bronowski, PiotrX > ; Ananyev, Konstantin > ; Thomas Monjalon > > Subject: RE: [dpdk-dev v4 1/4] cryptodev: add symmetric crypto data-path > APIs >=20 > Hi Fan, > > > > Hi Akhil, > > > > ... > > > > > > > > As you may have seen the structure definition is hW centric with th= e > > > > IOVA addresses all over. Also as you will from the patch series the > > > operation is > > > > Per operation basis instead of operating in a burst. The external > application > > > > may sooner know when a specific enqueue is failed. > > > > > > You may also need to save a virtual address as well. As some hardware > are > > > able to > > > Convert virtual to physical addresses on it's own giving a performanc= e > > > improvement. > > > > > > I do not see an issue in using enqueue burst with burst size=3D1 , bu= t since > you > > > are doing > > > Optimizations, none of the hardware can perform well with burst =3D 1= , I > think > > > it is always > > > Greater than 1. > > > > Shall I update the rte_crypto_sym_vec as the following - so the 2 probl= ems > can > > be > > resolved? > > > > 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; > > /** > > * array of statuses for each operation: > > * - 0 on success > > * - errno on error > > */ > > int32_t *status; > > }; > > > > /* Supposed to be used with HW crypto API call. */ > > struct { > > /** array of pointers to IV */ > > struct rte_crypto_vec *iv_hw; > > /** array of pointers to AAD */ > > struct rte_crypto_vec *aad_hw; > > /** array of pointers to Digest */ > > struct rte_crypto_vec *digest_hw; > > }; > > > > }; > > /** number of operations to perform */ > > uint32_t num; > > }; >=20 > Yes something of that sort can work. >=20 Will change it in v5. ... > > > > > Have you done some profiling with using rte_crypto_op instead of this > new > > > struct? > > > > > Yes, the code are actually upstreamed in VPP > > https://gerrit.fd.io/r/c/vpp/+/18036, please try out. If you > > have a look at the > > enqueue/dequeue functions you should see the struggle we had to > translate > > ops, and creating a second software ring to make sure we only dequeue a > > frame of data. Lucky VPP has space to store mbufs otherwise the perf wi= ll > > be even worse. > What is the performance gap do you see after making m_src and m_dst as > Raw buffers? >=20 Converting other projects data structure (such as VPP crypto op) into DPDK cryptodev operation introduces some performance degradation. >=20 > There may be some cases where a limited amount of control pkts can be sen= t > Which may be session less. We cannot ask people to use a different data > path > For such traffic. So we may need to support that too. >=20 Here is our proposal to the enqueue-dequeue API typedef uint32_t (*cryptodev_sym_hw_dp_crypto_enqueue_dequeue_t) (struct rte_cryptodev *dev, uint16_t qp_id, struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs ofs, struct rte_crypto_sym_vec *vec, void **opaque, int *enqueued_num, rte_cryptodev_get_dequeue_count_t get_dequeue_count, rte_cryptodev_post_dequeue_t post_dequeue, uint32_t flags); So the idea is a single API that does enqueue and/or dequeue combined. If the user wants to do enqueue she/he should have=20 RTE_CRYPTO_HW_DP_FF_DO_ENQUEUE in the flag, or=20 RTE_CRYPTO_HW_DP_FF_DO_DEQUEUE if dequeue is expected to be done. Opaque could be single pointer or an array, also specified by the flags, so If the user wants to do same as cryptodev_enqueue they can stores the Crypto ops into opaque_in, and the dequeued opaque will be stored in Opaque_out. There are 2 function pointers=20 rte_cryptodev_get_dequeue_count_t: return the number of jobs to dequeue, which helps if the user wants to know the dequeue count from first dequeued opaque data, or just return a fixed number same as cryptodev enqueue/dequeue usage. rte_cryptodev_post_dequeue_t: user provided function to operate post dequeue, good to write status to user specified data structure (opaque). To enable sessionless we may add the union number to replace sess. The union is either a session pointer or xform pointer, may be specified by the flag too.=20 You may ask why using a single function pointer for both enqueue and dequeue, instead 2 separate functions... I only intended to squeeze it into rte_cryptodev_ops to combine it with cryptodev_sym_cpu_crypto_process_t as a union, without expanding rte_cryptodev_ops size. struct rte_cryptodev_ops { ... cryptodev_asym_free_session_t asym_session_clear; /**< Clear a Crypto sessions private data. */ union { cryptodev_sym_cpu_crypto_process_t sym_cpu_process; /**< process input data synchronously (cpu-crypto). */ cryptodev_sym_hw_crypto_enqueue_dequeue_t sym_hw_enq_deq; /**< Get HW crypto data-path call back functions and data */ }; }; > > Rte_security is built on top of mbuf and ethdev and is not intended to > "mbuf- > > independent" > > applications either. Again we can replacing sess to the union of=20 union rte_cryptodev_hw_dp_ctx { struct rte_cryptodev_sym_session *crypto_sess; struct rte_crypto_sym_xform *xform; struct rte_security_session *sec_sess; }; >=20 > Rte_security for lookaside protocol can be mbuf independent and NXP may > Support it in future especially in case of PDCP. >=20 > Regards, > Akhil What do you think? Regards, Fan