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 22840A04AC; Mon, 31 Aug 2020 17:16:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 835AC1C0B0; Mon, 31 Aug 2020 17:16:21 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 5241F1C07B for ; Mon, 31 Aug 2020 17:16:19 +0200 (CEST) IronPort-SDR: VdU5TiVXPwOSREGSmSTl5ze4hgebuRdSCBdVUERvtyJ9LQ5VERK3LyBOeIoPQKbi+geRoafEtz vZCp4k7C471Q== X-IronPort-AV: E=McAfee;i="6000,8403,9730"; a="136520805" X-IronPort-AV: E=Sophos;i="5.76,376,1592895600"; d="scan'208";a="136520805" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Aug 2020 08:16:10 -0700 IronPort-SDR: V8xcYof+h81Nhte1lAmvxqeKFwRVvkLWBkWinp74sriKw50MPJrLpKXKCe7jD2/sFYy0y0jGfw XWWNR2PdaE1g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,376,1592895600"; d="scan'208";a="338252200" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by FMSMGA003.fm.intel.com with ESMTP; 31 Aug 2020 08:16:09 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 31 Aug 2020 08:15:50 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 31 Aug 2020 08:15:49 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 31 Aug 2020 08:15:49 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.177) 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; Mon, 31 Aug 2020 08:15:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yq35WjNJE1NhM4Vo9In2bNABeI/jxEVd7AHVzkrgKA6gpgjr1YTjGGYZnw9nxbpeaLRJVYWzePm3RDygwlP6DK3HA8Pnkh4fHFZgZ2eWP+Wo3RqnKosT75OrFEX4yLrGBEU1o9EGFkoZBeGSdC+HeoscVG/pw34RCl7/lEfUpmQ5JfO1dO+KdD4yNe3obJgyBWmsVQCHvUgdSstBufmq86bCXl0HxLg+M9i7Gb/4PUFI8K0G70tgLY8sJIRyYWIeAyrWrFWoDGZdAOb+CzxI34GfPiwC18mm5M/FzNj4TyiyIatg9dlYOlCzT61pJq+xkDjq6ayRjNxOXYHm+xTRYg== 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=VHX0Fq99COXhgwuyylYJvSu8T43049uDCtqMOzRIUMo=; b=mwfLJy+KzzPjyfCMiq63IZk7PwHV4soqOiOSmkQIJRK4OkBjKdjz4u2aMpM5KzA4k9UlazCY+mkqvuxu0WPem3lOqBUnx6u5ywHFeLTaMTrNC3vCUCtvybrHseRJlSzK6S1ratQT7aWtYuvaWFkTseT0qV7b4nQ3nZ12d/8nHfjU7yWIC1SruIC7Q8E8VlXpAkPShUpp7uMKGVj5wdbwWrpMD4vVOF+TEwDQ1gT8AAx52r8NMAJPwnQfxVBdI1psx8PknTNRQLJoAvwjfJn6Uu4TpiEusVL19wPoq+xCvxOk46lt5D1wp1sQCzD2vWSOja+1Ex6IAurEUK94xcFDUw== 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=VHX0Fq99COXhgwuyylYJvSu8T43049uDCtqMOzRIUMo=; b=JPVAfp92YxkK+f2f0KZ/VbFUu5yksC9fEqP9Hkw4O/Q/bWIVLa0wGxGLTaMkvQyA5Rfi+Tx+SRrfvTRGY4ciZIJFv1JiDzOvoGA3IbKU8vqY8Ny7Lm8BEGXXX7+EboFlx3SGngEovez0tuR7qOGn0RAWbUzK1BbP+lBEXxuCRC4= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by MN2PR11MB4335.namprd11.prod.outlook.com (2603:10b6:208:18d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.22; Mon, 31 Aug 2020 15:15:46 +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.3326.025; Mon, 31 Aug 2020 15:15:46 +0000 From: "Zhang, Roy Fan" To: "Kusztal, ArkadiuszX" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "Trahe, Fiona" , "Dybkowski, AdamX" , "Bronowski, PiotrX" Thread-Topic: [dpdk-dev v7 1/4] cryptodev: add crypto data-path service APIs Thread-Index: AQHWfTrsmsBR7PhRE06AEO+eQh5X46lRxCCAgACPCyA= Date: Mon, 31 Aug 2020 15:15:46 +0000 Message-ID: References: <20200818162833.20219-1-roy.fan.zhang@intel.com> <20200828125815.21614-1-roy.fan.zhang@intel.com> <20200828125815.21614-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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmEzNTQzMDItM2E5Yi00ZTMxLThmYjQtNDdhYjk2NDU5ZmY5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiU2l0bEJ4NUppcnd3ZEpQRVRoQ0J0S0ViYlFkTnRxempLRXg0MEJFRU1lQklXQ3JRWHRKOGM5VXIzZk5XQWp5MSJ9 x-ctpclassification: CTP_NT 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: 1b965f76-202a-447e-44bb-08d84dc0bcac x-ms-traffictypediagnostic: MN2PR11MB4335: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P6Rk+dFpkwLZu3cOpa0SH75DNTtzG2HMAGt8sg3WN4GV8Pia2EZgWtj2fYQMhos5rxPNY7y3VzwvqQO7lTSZrrSBz04CW0MtNMrx4YyOPmIkPedkK/kY8WdRq4QYzVASFDuX1/IPJBtM6se3HD7RL8ja3TW8yFfrbjysldy7k3cZUfQ4bZZFXwatODp3fWFSpacZHFvI5Rrrzbqe3rIbgdhW3fsYjC0qYNXJbJEFeMznQaX6HJEogSoam2BGdwDO+tXMxScR36w5qWPAZNy+loE9VWpMLIokhCxJrWEAMHif3jH44whdKb92nWZNe7rkes8+rDwyxEXTqN/fNgUYZg== 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)(366004)(136003)(39860400002)(396003)(376002)(346002)(9686003)(54906003)(66556008)(55016002)(66476007)(316002)(26005)(64756008)(66446008)(53546011)(6506007)(8676002)(7696005)(52536014)(186003)(83380400001)(66574015)(110136005)(71200400001)(2906002)(478600001)(4326008)(8936002)(86362001)(66946007)(107886003)(76116006)(5660300002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Q9jZUn6oWFudTODVz/mkh7AlgfY+JbylNnVKkAn32FxgKhqalO334LaIdnlgeLbIQXsOEKuVobdIpSSKOyGr1RCrJ4AP3xQW3osVd42ldUx1BuN/0x+6wervsWOOkhr3X2dVNSr/ClOgIVbguA/Jb2vHUJhnIC6dwrFKRXk7Dmu12eiipmfbk9nXTrpCaTYCa/ISRDM6IvE9jj02gikPfIgyZppUs2sq2K+BlvgE+5YPHA7YzSvzl5N19pDS+8shtHTbM5IkWd4SbFUNIat28UTbTgdajoJAAaJh+ZvTHlQUdKVqTwhUPhTi5W4OlJEVWHQgh6iVmN9T3+C9OXbgQUq2rKisUoxQtDK2IRtCFCik1yNngsgagfhbHmU9BYCgL2+8W5Kmbv0reTUHoRv6v/lvF+qE9RWcLv8EAfMUmgcBoukMtVGVUWWX+Fvv0I4rBWlib+LXCMkfOdxr6LP+iJRrS0uGIA9KXc9rfQ12bCzVZgTu+k1+dCDZBP8pUHDkwSK3iiAC9eiy2C2hxd6+EPLs5yVjHaMa9aSJYQOpEcFuj+LjGEoU9izfjdBpoylhqkVrW2SrRw0JbZvclsAcyoyGCLh1z/UEiwbqNwpF/0ecaF1xKyBfnUT3d+u+f5nFfPc3KBf0Nit3ReGKKMY++A== Content-Type: text/plain; charset="iso-8859-2" 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: 1b965f76-202a-447e-44bb-08d84dc0bcac X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 15:15:46.4122 (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: PMzcBNQz+l/zP0olDnudphD93eOe+E1s32eNsuBCvCHh93xk2ZV1Jcaa2L7VPZvhTUopXiq61S3WsinVfNOy+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4335 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [dpdk-dev v7 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 Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Monday, August 31, 2020 7:24 AM > To: Zhang, Roy Fan ; dev@dpdk.org > Cc: akhil.goyal@nxp.com; Trahe, Fiona ; Dybkowski, > AdamX ; Bronowski, PiotrX > > Subject: RE: [dpdk-dev v7 1/4] cryptodev: add crypto data-path service AP= Is >=20 > Hi Fan, Piotrek, >=20 > -----Original Message----- > From: Zhang, Roy Fan > Sent: pi=B1tek, 28 sierpnia 2020 14:58 > To: dev@dpdk.org > Cc: akhil.goyal@nxp.com; Trahe, Fiona ; Kusztal, > ArkadiuszX ; Dybkowski, AdamX > ; Zhang, Roy Fan ; > Bronowski, PiotrX > Subject: [dpdk-dev v7 1/4] cryptodev: add crypto data-path service APIs >=20 > This patch adds data-path service APIs for enqueue and dequeue operations > to cryptodev. The APIs support flexible user-define enqueue and dequeue > behaviors and operation mode. >=20 > Signed-off-by: Fan Zhang > Signed-off-by: Piotr Bronowski > --- > lib/librte_cryptodev/rte_crypto.h | 9 + > lib/librte_cryptodev/rte_crypto_sym.h | 44 ++- > lib/librte_cryptodev/rte_cryptodev.c | 45 +++ > lib/librte_cryptodev/rte_cryptodev.h | 335 +++++++++++++++++- > lib/librte_cryptodev/rte_cryptodev_pmd.h | 47 ++- > .../rte_cryptodev_version.map | 10 + > 6 files changed, 481 insertions(+), 9 deletions(-) >=20 > +/** Crypto data-path service types */ > +enum rte_crypto_dp_service { > + RTE_CRYPTO_DP_SYM_CIPHER_ONLY =3D 0, > + RTE_CRYPTO_DP_SYM_AUTH_ONLY, > + RTE_CRYPTO_DP_SYM_CHAIN, > [Arek] - if it is auth-cipher/cipher-auth will be decided thanks to > sym_session/xform? [Fan] - yes. > + RTE_CRYPTO_DP_SYM_AEAD, > + RTE_CRYPTO_DP_N_SERVICE ... > + || dev->dev_ops->configure_service =3D=3D NULL) > + return -1; > + > [Arek] - Why to change order of arguments between > rte_cryptodev_dp_configure_service and configure_service pointer? Except > of dev and dev_id they all are the same. [Fan] - I will update. =20 > + * Submit a data vector into device queue but the driver will not start > + * processing until rte_cryptodev_dp_sym_submit_vec() is called. > [Arek] " until ``rte_cryptodev_dp_submit_done`` function is called " ? [Fan] - Yes, will update. Sorry for it. =20 >=20 > + * > + * @param qp Driver specific queue pair data. > + * @param service_data Driver specific service data. > + * @param vec The array of job vectors. > + * @param ofs Start and stop offsets for auth and cipher > + * operations. > + * @param opaque The array of opaque data for > dequeue. > + * @return > + * - The number of jobs successfully submitted. > + */ > +typedef uint32_t (*cryptodev_dp_sym_submit_vec_t)( > + void *qp, uint8_t *service_data, struct rte_crypto_sym_vec *vec, > + union rte_crypto_sym_ofs ofs, void **opaque); > + > +/** > + * Submit single job into device queue but the driver will not start > + * processing until rte_cryptodev_dp_sym_submit_vec() is called. > [Arek] until ``rte_cryptodev_dp_submit_done`` function is called " as abo= ve. [Fan] - Yes, will update. Sorry for it. > + * > + * @param qp Driver specific queue pair data. > + * @param service_data Driver specific service data. > + * @param data The buffer vector. > + * @param n_data_vecs Number of buffer vectors. > + * @param ofs Start and stop offsets for auth and cipher > + * operations. > + * @param iv IV data. > + * @param digest Digest data. > + * @param aad AAD data. > + * @param opaque The opaque data for dequeue. > + * @return > + * - On success return 0. > + * - On failure return negative integer. > [Arek] How can we distinguish between malformed packet and full queue? [Fan] We may have to rely on the application to track the inflight ops.=20 We want to avoid use enqueue_burst same as rte_cryptodev_enqueue_burst, as the caller application and the PMD has to loop the same job burst 2 time= s to write and read the job content (cause >5% perf loss). The best option is providin= g an inline function to enqueue one job at a time and provides the capability of abando= ning the enqueue if not all expected jobs are enqueued. So the idea is to create a s= hadow copy of the device's queue stored in the user application and then have the capa= bility to abandon the enqueue when not all expected jobs are enqueued. The necessa= ry check has to be made by the driver when merging the user's local queue data= into PMD's queue data. > + */ > +typedef int (*cryptodev_dp_submit_single_job_t)( > + void *qp, uint8_t *service_data, struct rte_crypto_vec *data, > + uint16_t n_data_vecs, union rte_crypto_sym_ofs ofs, > + struct rte_crypto_data *iv, struct rte_crypto_data *digest, > + struct rte_crypto_data *aad, void *opaque); > + > +/** > +struct rte_crypto_dp_service_ctx { > + void *qp_data; > + > + union { > [Arek] - Why union? It will be extended by other structs in future? [Fan] - yes, maybe used by asymmetric crypto in the future. =20 > [Arek] - unnamed union and struct, C11 extension. [Fan] Will correct it. > + /* Supposed to be used for symmetric crypto service */ > + struct { > + cryptodev_dp_submit_single_job_t > submit_single_job; > + cryptodev_dp_sym_submit_vec_t submit_vec; > + cryptodev_dp_sym_operation_done_t submit_done; > + cryptodev_dp_sym_dequeue_t dequeue_opaque; > + cryptodev_dp_sym_dequeue_single_job_t > dequeue_single; > + cryptodev_dp_sym_operation_done_t > dequeue_done; > + }; > + }; > + > + /* Driver specific service data */ > + uint8_t drv_service_data[]; > [Arek] - flexible array, C99 so again extension [Fan] Will correct it. > +}; > + > +/** > + * Configure one DP service context data. Calling this function for the > +first > + * time the user should unset the *is_update* parameter and the driver > +will > + * fill necessary operation data into ctx buffer. Only when > + * rte_cryptodev_dp_submit_done() is called the data stored in the ctx > +buffer > + * will not be effective. > + * > + * @param dev_id The device identifier. > + * @param qp_id The index of the queue pair from which to > + * retrieve processed packets. The value must > be > + * in the range [0, nb_queue_pair - 1] > previously > + * supplied to rte_cryptodev_configure(). > + * @param service_type Type of the service requested. > + * @param sess_type session type. > + * @param session_ctx Session context data. > + * @param ctx The data-path service context data. > + * @param is_update Set 1 if ctx is pre-initialized but need > + * update to different service type or session, > + * but the rest driver data remains the same. > [Arek] - if user will call it only once with is_update =3D=3D 1 will ther= e be any error > shown about ctx not set when started processing or is it undefined behavi= or? [Fan] - the driver will not know the difference so we may have to rely on = the user to set this correctly > + rte_cryptodev_dp_configure_service; > + rte_cryptodev_get_dp_service_ctx_data_size; >=20 >=20 > [Arek] - I know its experimental but following 6 functions are not only s= tatic > but __always_inline__ too, I doubt there will be any symbol generated, > should they be placed inside map file then? [Fan] the symbols are not generated. I also have the same question - do we = need to place them in the map file? > [Arek] - Another thing since symbol is not created these funcs are outsid= e of > abidifftool scope of interest either I think. >=20 > + rte_cryptodev_dp_submit_single_job; > + rte_cryptodev_dp_sym_submit_vec; > + rte_cryptodev_dp_submit_done; > + rte_cryptodev_dp_sym_dequeue; > + rte_cryptodev_dp_sym_dequeue_single_job; > + rte_cryptodev_dp_dequeue_done; > }; >=20 > [Arek] - Two small things: > - rte_crypto_data - there is many thing in asymmetric/symmetric > crypto that can be called like that, and this is basically symmetric > encrypted/authenticated data pointer, maybe some more specific name > could be better. > - can iv, digest, aad be grouped into one? All share the same features, > and there would less arguments to functions. [Fan] - answered in the last email. Grouping is a good idea but may limit t= he usage. We need a structure that does not necessarily contains the length info for = all data pre-defined when creating the sessions. > -- > 2.20.1