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 C21CCA04A2; Tue, 5 Nov 2019 22:41:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0CAE31BF58; Tue, 5 Nov 2019 22:41:47 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40082.outbound.protection.outlook.com [40.107.4.82]) by dpdk.org (Postfix) with ESMTP id 20AA91BF53; Tue, 5 Nov 2019 22:41:44 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JsPB6bjV4hGHGB0HdX6IMglcT3NKClSdqQpJheWr5YTafc0Gw5Kxrk8hNH6Ja9n4Oh6sKIubl2nYR9Mu2Sd1kGNb0QBFQ0JBQui5RyYIRx8QJODzqw8GXXOa9mZFiTTB3NJJY+T2pkR6mW88SHhdQM0PZ1ayGKnCiHGSp45/6nifRAI2BzsMdc8Bmr1GMlocwwHXQ1VS61lZyrjPwOio0onUpgTIFZFW/9eeLkQKwtBpwAnd0lTziu6DokLVJhkqK+zoz1Pia3QXaTabNJ7DlvRWSTCAe7UsCQr43R+FIta/q4eW9IzbCQXFMBl9TiLiX7OPDvnUI0kuGPzVQZ8Kmg== 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=33hbzJtCGcVJSeJ487UWF75ydah6WJzmysrAg2uez4E=; b=Bdg7rKpR44whQiX6DL3Dj8h+W65BYhUl2PT17Gr294Ah4DYlTdpF8xbWoErrqnD17GNAHkN4dqE+/XEF5+nl1D4AL/1AeniVInPqggzRNap+svzdpBdWC1dhKsjg9t8J8EZpeF259JbJayKDZraqbANWUkwr7TJNsCL+4pms6nnaD6UjdVtGNcuEk7ZWc5dRbw8vigEN4hNr8Rc8gN25tf3qT2GgqQZqb2wFnYRCLm4a80/ZLia8ZzOKxnF8Q3EfpXzd+u1p+AoA28DVgq1b52DuMuzd146kdl7pcq/wRzqL5CUYeg2sdIqjh55A1uM6p1Fd++P1f4nnjeJpa3f/Ng== 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=33hbzJtCGcVJSeJ487UWF75ydah6WJzmysrAg2uez4E=; b=Bria7Ryt8eIDHfKOvs5oSXQBoKGD41IgSyeXN0hBMx+uVjnVrwX32CF8BhXyfdbxa4zF6IwbqDW0dDt6pn8GeGCUA4RpkfWyVz1tXSA84+udDQUztm1NYri83sbrxNNkkOnIoOIih1MHeJUjGoTT6y82Mc9z0E2ssLURwWvNW4w= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (10.255.118.11) by VE1PR04MB6752.eurprd04.prod.outlook.com (20.179.234.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 21:41:43 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::9dc:aa5c:2bb8:b561]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::9dc:aa5c:2bb8:b561%6]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019 21:41:43 +0000 From: Akhil Goyal To: Konstantin Ananyev , "dev@dpdk.org" , "techboard@dpdk.org" CC: "roy.fan.zhang@intel.com" , "declan.doherty@intel.com" Thread-Topic: [RFC 3/4] cryptodev: introduce cpu-crypto API Thread-Index: AQHVlAi/RYOFzfdo50Cz76eFltd2zKd9GWoQ Date: Tue, 5 Nov 2019 21:41:43 +0000 Message-ID: References: <20191105184122.15172-1-konstantin.ananyev@intel.com> <20191105184122.15172-4-konstantin.ananyev@intel.com> In-Reply-To: <20191105184122.15172-4-konstantin.ananyev@intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [223.190.56.205] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bbf90b15-f493-490d-8b4c-08d76238f311 x-ms-traffictypediagnostic: VE1PR04MB6752: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(189003)(199004)(76176011)(229853002)(476003)(478600001)(2201001)(66476007)(186003)(486006)(2501003)(66446008)(66066001)(66556008)(6506007)(446003)(11346002)(256004)(54906003)(8936002)(305945005)(7736002)(4326008)(33656002)(81156014)(8676002)(81166006)(71200400001)(74316002)(6246003)(6116002)(2906002)(3846002)(5660300002)(44832011)(64756008)(25786009)(86362001)(76116006)(66946007)(14454004)(7696005)(316002)(110136005)(71190400001)(99286004)(14444005)(55016002)(52536014)(6436002)(26005)(102836004)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6752; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mmYsYwtue958JFdpJSTtqYrDlhNVIHBa2dzgdjQVnD57tumqhYx21ejyKqBfHEKGounS23GjxuMHLWcZaBwXjuXTKoyyLkPx7oO0tYU7Cqi1OsdagR2hZ84Og8YvmAAcDdWBc9SPdU9qK5HxAtYInwfQpFtjR2F+OgqhKPPnVGjPdsgvW3iL+mglL+z4wfKTzjaxIUg9oI32jAFHB+R3TxS6Ws9xMI4Sro5U1EzuxMTP/ApYSTizC1yyUPx0ETYk/zR8FI624rug/xD4bPZoYmyGlPxzZOlmg5I0d8Se9082fDw+h059kvR38FTAETC6CR2hyarL71ip+e+HIPR4axgsLWFW6dIq1BQsEtLvk+uFipXxsdanRP4Amclljke44oAGk5l4PiH0VGrMFZSFOssPfnv8zhWXvUx7HOfyRJ+C8l6uBnLHQLV8E0tyvcCY 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-Network-Message-Id: bbf90b15-f493-490d-8b4c-08d76238f311 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 21:41:43.1028 (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: 4nsxZ3QvsHB3870wb+s/p3iV1whyB+z2SlB2myEgQMrpDnozj4mavbkCQ6CUL8MITgGUIEQzUfbmYynyf43dHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6752 Subject: Re: [dpdk-dev] [RFC 3/4] cryptodev: introduce cpu-crypto API 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, >=20 > This patch extends rte_cryptodev API with CPU-CRYPTO mode. > This is done by reusing existing rte_crypto_sym_session structure itself > and related control-path cryptodev API (init/clear/get_size/etc.) > For data-path new sym_cpu_ process() function is added into > rte_cryptodev dev_ops. >=20 > Crypto PMD that wants to support that functionality would need to: > 1. claim RTE_CRYPTODEV_FF_SYM_CPU_CRYPTO capability supported. > 2. change at least the following functions inside rte_cryptodev_ops: > . sym_session_get_size, > . sym_session_configure, > . sym_session_clear > to accommodate support for both sync and async modes, > 3. implement new function inside rte_cryptodev_ops: > sym_cpu_process >=20 > For data-path processing consumer of that API would have to maintain: > struct rte_cryptodev_sym_session *sess, > list of dev ids for which this session was properly initialized >=20 > As an advantage of this approach - reuse of existing API > and minimal visible changes for crypto PMDs. >=20 > Signed-off-by: Konstantin Ananyev > --- > lib/librte_cryptodev/rte_crypto_sym.h | 11 ++++++++++- > lib/librte_cryptodev/rte_cryptodev.c | 14 ++++++++++++++ > lib/librte_cryptodev/rte_cryptodev.h | 24 ++++++++++++++++++++++++ > lib/librte_cryptodev/rte_cryptodev_pmd.h | 22 ++++++++++++++++++++++ > 4 files changed, 70 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h > b/lib/librte_cryptodev/rte_crypto_sym.h > index d8d9e9514..790c77524 100644 > --- a/lib/librte_cryptodev/rte_crypto_sym.h > +++ b/lib/librte_cryptodev/rte_crypto_sym.h > @@ -166,6 +166,10 @@ struct rte_crypto_cipher_xform { > * - Both keys must have the same size. > **/ >=20 > + /** > + * CPU-CRYPTO specific data, should be set properly when > + * (xform->type & RTE_CRYPTO_SYM_CPU_CRYPTO) !=3D 0, otherwise > ignored. > + */ > struct { > /** > * offset for cipher to start within user provided data buffer. Earlier I was ok to have this offset but on another thought, why do you nee= d this? User can give the exact pointer in the process() API from where he wants to= do ciphering. You will be adding this offset in the driver if you keep this in xform/sess= ion. So I think there is no difference whether you add in the driver or the application. Am I missin= g something? > @@ -415,6 +419,10 @@ struct rte_crypto_aead_xform { > uint16_t length; /**< key length in bytes */ > } __attribute__((__packed__)) key; >=20 > + /** > + * CPU-CRYPTO specific data, should be set properly when > + * (xform->type & RTE_CRYPTO_SYM_CPU_CRYPTO) !=3D 0, otherwise > ignored. > + */ > struct { > /** > * offset for cipher to start within user provided data buffer. > @@ -471,7 +479,8 @@ enum rte_crypto_sym_xform_type { > RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED =3D 0, /**< No xform > specified */ > RTE_CRYPTO_SYM_XFORM_AUTH, /**< Authentication > xform */ > RTE_CRYPTO_SYM_XFORM_CIPHER, /**< Cipher xform */ > - RTE_CRYPTO_SYM_XFORM_AEAD /**< AEAD xform */ > + RTE_CRYPTO_SYM_XFORM_AEAD, /**< AEAD xform */ > + RTE_CRYPTO_SYM_CPU_CRYPTO =3D INT32_MIN, /**< xform for cpu- > crypto */ This is not a correct place to have this. All types of xforms CIPHER/AUTH/A= EAD=20 can be used in SYNC mode > }; >=20 > /** > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > b/lib/librte_cryptodev/rte_cryptodev.c > index 89aa2ed3e..b1dbaf4c1 100644 > --- a/lib/librte_cryptodev/rte_cryptodev.c > +++ b/lib/librte_cryptodev/rte_cryptodev.c > @@ -1616,6 +1616,20 @@ rte_cryptodev_sym_session_get_user_data( > return (void *)(sess->sess_data + sess->nb_drivers); > } >=20 > +__rte_experimental > +int > +rte_cryptodev_sym_cpu_crypto_process(uint8_t dev_id, > + struct rte_cryptodev_sym_session *sess, struct rte_crypto_sym_vec > *vec, > + int32_t status[], uint32_t num) > +{ > + struct rte_cryptodev *dev; > + > + dev =3D rte_cryptodev_pmd_get_dev(dev_id); > + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_cpu_process,- > ENOTSUP); > + > + return dev->dev_ops->sym_cpu_process(dev, sess, vec, status, num); > +} > + > /** Initialise rte_crypto_op mempool element */ > static void > rte_crypto_op_init(struct rte_mempool *mempool, > diff --git a/lib/librte_cryptodev/rte_cryptodev.h > b/lib/librte_cryptodev/rte_cryptodev.h > index c6ffa3b35..24877006c 100644 > --- a/lib/librte_cryptodev/rte_cryptodev.h > +++ b/lib/librte_cryptodev/rte_cryptodev.h > @@ -450,6 +450,8 @@ rte_cryptodev_asym_get_xform_enum(enum > rte_crypto_asym_xform_type *xform_enum, > /**< Support encrypted-digest operations where digest is appended to dat= a */ > #define RTE_CRYPTODEV_FF_ASYM_SESSIONLESS (1ULL << 20) > /**< Support asymmetric session-less operations */ > +#define RTE_CRYPTODEV_FF_SYM_CPU_CRYPTO > (1ULL << 21) > +/**< Support symmeteric cpu-crypto processing */ >=20 >=20 > /** > @@ -1274,6 +1276,28 @@ void * > rte_cryptodev_sym_session_get_user_data( > struct rte_cryptodev_sym_session > *sess); >=20 > +/** > + * Perform actual crypto processing (encrypt/digest or auth/decrypt) > + * on user provided data. > + * > + * @param dev_id The device identifier. > + * @param sess Cryptodev session structure > + * @param vec Array of vectors for input data > + * @param status Array of status values (one per vec) > + * (RTE_CRYPTO_OP_STATUS_* values) > + * @param num Number of elems in vec and status arrays. > + * > + * @return > + * - Returns negative errno value on error, or non-negative number > + * of successfully processed input vectors. > + * > +*/ > +__rte_experimental > +int > +rte_cryptodev_sym_cpu_crypto_process(uint8_t dev_id, > + struct rte_cryptodev_sym_session *sess, struct rte_crypto_sym_vec > *vec, > + int32_t status[], uint32_t num); > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h > b/lib/librte_cryptodev/rte_cryptodev_pmd.h > index fba14f2fa..02e7a19ae 100644 > --- a/lib/librte_cryptodev/rte_cryptodev_pmd.h > +++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h > @@ -308,6 +308,26 @@ typedef void (*cryptodev_sym_free_session_t)(struct > rte_cryptodev *dev, > */ > typedef void (*cryptodev_asym_free_session_t)(struct rte_cryptodev *dev, > struct rte_cryptodev_asym_session *sess); > +/** > + * Perform actual crypto processing (encrypt/digest or auth/decrypt) > + * on user provided data. > + * > + * @param dev Crypto device pointer > + * @param sess Cryptodev session structure > + * @param vec Array of vectors for input data > + * @param status Array of status values (one per vec) > + * (RTE_CRYPTO_OP_STATUS_* values) > + * @param num Number of elems in vec and status arrays. > + * > + * @return > + * - Returns negative errno value on error, or non-negative number > + * of successfully processed input vectors. > + * > +*/ > +typedef int (*cryptodev_sym_cpu_crypto_process_t)(struct rte_cryptodev *= dev, > + struct rte_cryptodev_sym_session *sess, struct rte_crypto_sym_vec > *vec, > + int32_t status[], uint32_t num); > + >=20 > /** Crypto device operations function pointer table */ > struct rte_cryptodev_ops { > @@ -342,6 +362,8 @@ struct rte_cryptodev_ops { > /**< Clear a Crypto sessions private data. */ > cryptodev_asym_free_session_t asym_session_clear; > /**< Clear a Crypto sessions private data. */ > + cryptodev_sym_cpu_crypto_process_t sym_cpu_process; > + /**< process input data synchronously (cpu-crypto). */ > }; >=20 >=20 > -- > 2.17.1