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 655FCA04DD; Fri, 23 Oct 2020 14:36:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 208A6A945; Fri, 23 Oct 2020 14:36:39 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1F4C17F45 for ; Fri, 23 Oct 2020 14:36:35 +0200 (CEST) IronPort-SDR: rLS9B5an4x3eLbKT9YVIZ5BTASeYiNJbFKUGvoBZE1D1HPHi+Mxj2tEs8+uVTE19RPgLHzb1qh j7fgV0BvNxwQ== X-IronPort-AV: E=McAfee;i="6000,8403,9782"; a="229302373" X-IronPort-AV: E=Sophos;i="5.77,408,1596524400"; d="scan'208";a="229302373" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2020 05:36:30 -0700 IronPort-SDR: S0NZIKGo03p3AVz9rgWpMoTnZBLYXJfXuvj7STEgGQkEa1UXleptkFfMLNoVpQfU1S10XFmG4J 2nNsh4webekw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,408,1596524400"; d="scan'208";a="534381865" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga005.jf.intel.com with ESMTP; 23 Oct 2020 05:36:28 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 23 Oct 2020 05:36:28 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 23 Oct 2020 05:36:27 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) 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; Fri, 23 Oct 2020 05:36:27 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 23 Oct 2020 05:36:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TeZYHTk0PwfgysU/AxucPJM8fjeLUiQqCIGqkB36qSXncoLRHBIKqE+FGKhjj3L0G0l1konKYkpvQxdoBtfHA4M/wCgP3RcwWnkdUN3FWTJFc3OJ9kvPhpYdAixpb0RIl9pa5gNWSjJr06LC6s+yLN8tdtGIIT0obuy3Uf5+PeoShIBVW5Jg2T7oDJ3ilrXn2o0WbF0HPAPPyhH1d8nGxc6NPFpCElIznT2gYq25+A57WEyS1HSZQK3h0xLAa//Kc9Kh9m/5ufkLAe4vMhANBZRfaGCXi2wyOwU7d5Uv/CrOz4W5CXSFQlmWzPxaIoIBGaZlj1fPMNbNo8wI8OpB7A== 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=2FrtXBAGR6ObTJj2+aNCy9u1eu4xV8ba7pNl2oVwcqU=; b=arc3ht2NFWQjjl/psqwu0q3IdTyyLmwJ5ZHx+E4r1tyCSoqw8Xp2UZNl5Djmxt3JXPR0NbDZ5rhfUTqnq6xwjhLMs+8tKcWPDmx4G4kivsINgtrr004F5V7f4hmiUB8S547Z9WxKsy4uAvYKvFLIGR9TB75Vzvfw0A9FTcFtFZjfkcIN0TeIE83lnDyYBcZNWtFJwbIs52bGxMGzmua9puxsDOvAdUWK0DaSW2nMKr63guRjYemjnps0rXE2i3IVdn8qY2cu9BgYe/81fPIy17ep9+GWl9DdC2d8hqndzENV8g7WHHEfS075zJAR4kHQjDK55+lGkTez06aRx+QsKA== 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=2FrtXBAGR6ObTJj2+aNCy9u1eu4xV8ba7pNl2oVwcqU=; b=NA+PiL+88oSYOgdlARsMbJS8mOTAs8l8uQ7W3WQEjfOjRX4BVA/gWCKGi2/qwo69ODl5eRr7qsea1IqitU2IbDq5Pz9PrVvgOD3AmuB5iXkIqjLK3NLqDyP4f1i/mwi5OyIl85HaSkJcL5tu1z5abOvVNBYkW/6fIqY2LumXu24= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (2603:10b6:300:10c::11) by MW3PR11MB4635.namprd11.prod.outlook.com (2603:10b6:303:2c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Fri, 23 Oct 2020 12:36:23 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::20fb:cc03:ce89:f0ea]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::20fb:cc03:ce89:f0ea%7]) with mapi id 15.20.3499.018; Fri, 23 Oct 2020 12:36:23 +0000 From: "Gujjar, Abhinandan S" To: "Ananyev, Konstantin" , "dev@dpdk.org" , "Doherty, Declan" , "akhil.goyal@nxp.com" , "Honnappa.Nagarahalli@arm.com" CC: "Vangati, Narender" , "jerinj@marvell.com" Thread-Topic: [v3 1/2] cryptodev: support enqueue callback functions Thread-Index: AQHWptlSpDvoMhnzcEKPDHJ0ztw98KmidIEAgAKvrCA= Date: Fri, 23 Oct 2020 12:36:23 +0000 Message-ID: References: <1603076242-41883-1-git-send-email-abhinandan.gujjar@intel.com> <1603076242-41883-2-git-send-email-abhinandan.gujjar@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: [157.49.187.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ae86ea3-407b-4def-1855-08d8775040ac x-ms-traffictypediagnostic: MW3PR11MB4635: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AVnzarsQ4ajfqwRmpfCDVE8KTC23hWUZF/IjiepMt3CmYjgHrQfHkEtevTnWI6GDesDgaWck/ORNSBEUrz60nRM6KmHIYeaEOfQtyPPxP4YR+eq7EYnOWP9BAviYvcOOPbJDVwNsExQyLt0oJdy0D5hE7GPMQDvX6nGjLaPZmmMDvzZQrcvsDb545yMRpPge78ipkErgWF+mKGECHCbuyoLbj9+YDLLAU4qL2B6O98+yX6Gwcrp9k+4s+IaKO7BYNWp1OyYR94pWBfCC06f+6w5GVxn2SZhDM51khea7qnj+dgPDZV+gbXpQPe0WCb+8eImfczWXE/qBkBveetgwSQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1838.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(66446008)(64756008)(55016002)(54906003)(66556008)(83380400001)(66946007)(6506007)(9686003)(76116006)(86362001)(8936002)(7696005)(66476007)(53546011)(4326008)(26005)(52536014)(71200400001)(186003)(30864003)(8676002)(2906002)(316002)(478600001)(5660300002)(110136005)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Mg5sjtDZYU7m2PAWsXveEw8sHLHDCP9ajJiZeOb8Fi40Tx6pxKXiU2Yw6h8GlWz/+zOA7dz6JI3Da/HIZJGWcCFUQ2t6EmCFx1A5Oj9PQKxkusF01vFIAuo5mP6Vx+ZFrHnHrYh/lb6wTcoZS9VLiuxOmqX3poq4TMmdmylXc0vz4flWdXyalPjP7Os6DPIVRUS/ZotFYroSYHLGzArduKICrvqy9DzgO4LhLRCTADq47AfpZVLGFOuGdTSHeZiyXbILIBPVj39V3zvayexnfLOFqdn8PGhPjWuEu+eJbiOGHeUwbyO+auAM/OvlHttFycrvEqKA917BWHP/YVK7nTUov/H1vMYYQgAqOIoT3Izl944hItQxmhn6ZZMDTkuQjwHtJrv52HYL1IVoGWtk1YddiDV6wipuIwAjWWnreNn5bO6uKKmg/5dN/9U+2Li7UpidPo4W5IXFVyaQcugUoWwCP78cHHNevgtD3w2dCxZkjJcG2ISx8RWs66/zqN2c9gjTXC1UVpdjzXcJQwdG92dk4DnTgVK5zBpunHjC59WrWO6qC7RBwndKPCCp7+4LtRhVUBPFUybUldUGpbFNeIcEUZm5sIH8iU/wXLIq+kjRz8nW9jAiybUYchejg8bkZ9MndFNV7eunO9jFG8CbTQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1838.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ae86ea3-407b-4def-1855-08d8775040ac X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2020 12:36:23.8324 (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: 1xtwiZbtKnwrXE5ioBoKMtbZXodNmtCdxryMG1I/eryCw7vjlZur3lr8fmlBMb7OuiL53/+BRdZaotyYVjAb5A363K4r+ohcupT9s4oYR8E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4635 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [v3 1/2] cryptodev: support enqueue callback functions 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, Thanks. I will generate a new patch with suggested changes. > -----Original Message----- > From: Ananyev, Konstantin > Sent: Thursday, October 22, 2020 1:04 AM > To: Gujjar, Abhinandan S ; dev@dpdk.org; > Doherty, Declan ; akhil.goyal@nxp.com; > Honnappa.Nagarahalli@arm.com > Cc: Vangati, Narender ; jerinj@marvell.com > Subject: RE: [v3 1/2] cryptodev: support enqueue callback functions >=20 >=20 > Hi Abhinandan, >=20 > Thanks for the effort, good progress. > Though few more comments, see below. >=20 > > This patch adds APIs to add/remove callback functions. The callback > > function will be called for each burst of crypto ops received on a > > given crypto device queue pair. > > > > Signed-off-by: Abhinandan Gujjar > > --- > > config/rte_config.h | 1 + > > lib/librte_cryptodev/meson.build | 2 +- > > lib/librte_cryptodev/rte_cryptodev.c | 201 > +++++++++++++++++++++++++ > > lib/librte_cryptodev/rte_cryptodev.h | 153 +++++++++++++++++= +- > > lib/librte_cryptodev/rte_cryptodev_version.map | 2 + > > 5 files changed, 357 insertions(+), 2 deletions(-) >=20 > Don't forget to update Release Notes and probably Prog Guide too. >=20 > > > > diff --git a/config/rte_config.h b/config/rte_config.h index > > 03d90d7..e999d93 100644 > > --- a/config/rte_config.h > > +++ b/config/rte_config.h > > @@ -61,6 +61,7 @@ > > /* cryptodev defines */ > > #define RTE_CRYPTO_MAX_DEVS 64 > > #define RTE_CRYPTODEV_NAME_LEN 64 > > +#define RTE_CRYPTO_CALLBACKS 1 > > > > /* compressdev defines */ > > #define RTE_COMPRESS_MAX_DEVS 64 > > diff --git a/lib/librte_cryptodev/meson.build > > b/lib/librte_cryptodev/meson.build > > index c4c6b3b..8c5493f 100644 > > --- a/lib/librte_cryptodev/meson.build > > +++ b/lib/librte_cryptodev/meson.build > > @@ -9,4 +9,4 @@ headers =3D files('rte_cryptodev.h', > > 'rte_crypto.h', > > 'rte_crypto_sym.h', > > 'rte_crypto_asym.h') > > -deps +=3D ['kvargs', 'mbuf'] > > +deps +=3D ['kvargs', 'mbuf', 'rcu'] > > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > > b/lib/librte_cryptodev/rte_cryptodev.c > > index 3d95ac6..5ba774a 100644 > > --- a/lib/librte_cryptodev/rte_cryptodev.c > > +++ b/lib/librte_cryptodev/rte_cryptodev.c > > @@ -448,6 +448,10 @@ struct > rte_cryptodev_sym_session_pool_private_data { > > return 0; > > } > > > > +#ifdef RTE_CRYPTO_CALLBACKS > > +/* spinlock for crypto device enq callbacks */ static rte_spinlock_t > > +rte_cryptodev_enq_cb_lock =3D RTE_SPINLOCK_INITIALIZER; #endif > > > > const char * > > rte_cryptodev_get_feature_name(uint64_t flag) @@ -1136,6 +1140,203 @@ > > struct rte_cryptodev * > > socket_id); > > } > > > > +#ifdef RTE_CRYPTO_CALLBACKS > > + > > +struct rte_cryptodev_cb * > > +rte_cryptodev_add_enq_callback(uint8_t dev_id, > > + uint16_t qp_id, > > + rte_cryptodev_callback_fn cb_fn, > > + void *cb_arg) > > +{ > > + struct rte_cryptodev *dev; > > + struct rte_cryptodev_cb *cb, *tail; > > + struct rte_cryptodev_enq_cb_rcu *list; > > + struct rte_rcu_qsbr *qsbr; > > + size_t size; > > + > > + /* Max thread set to 1, as one DP thread accessing a queue-pair */ > > + const uint32_t max_threads =3D 1; > > + > > + if (!cb_fn) > > + return NULL; > > + > > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) { > > + CDEV_LOG_ERR("Invalid dev_id=3D%d", dev_id); > > + return NULL; > > + } > > + > > + dev =3D &rte_crypto_devices[dev_id]; > > + if (qp_id >=3D dev->data->nb_queue_pairs) { > > + CDEV_LOG_ERR("Invalid queue_pair_id=3D%d", qp_id); > > + return NULL; > > + } > > + > > + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock); > > + if (dev->enq_cbs =3D=3D NULL) { > > + dev->enq_cbs =3D rte_zmalloc(NULL, sizeof(cb) * > > + dev->data->nb_queue_pairs, 0); > > + if (dev->enq_cbs =3D=3D NULL) { > > + CDEV_LOG_ERR("Failed to allocate memory for > callbacks"); > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); >=20 > It is a bit clumsy to do unlock() for every return with error. > Probably an easier way - create an internal function that would do the a= ctual > job, and then lock(); ret=3Dactual_job_internal_functio(...); unlock();..= . >=20 > > + rte_errno =3D ENOMEM; > > + return NULL; > > + } > > + > > + list =3D rte_zmalloc(NULL, sizeof(*list), 0); >=20 > As I understand, list is per queue, while enq_cbs[] is per port. > So if enq_cbs is not null, it doesn't mean that list for that particular = queue is > already properly initialized. >=20 > Another thing - is there any point for dev->enq_cbs[] to be a an array of > pointers to rte_cryptodev_enq_cb_rcu? Considering that > rte_cryptodev_enq_cb_rcu itself contains just two pointers inside, I thin= k it > enq_cbs can point just to an array of rte_cryptodev_enq_cb_rcu: >=20 > struct rte_cryptodev { > ... > struct rte_cryptodev_enq_cb_rcu *enq_cbs; >=20 > And you can remove one level of indirection here and in other places. >=20 > > + if (list =3D=3D NULL) { > > + CDEV_LOG_ERR("Failed to allocate memory for list on > " > > + "dev=3D%d, queue_pair_id=3D%d", dev_id, qp_id); > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + rte_errno =3D ENOMEM; > > + rte_free(dev->enq_cbs); >=20 > Here and in other places: you free dev->enq_cbs, but not set it to NULL. > In fact - probably a good idea to have one cleanup() function that would = free all > necessary stuff and set it to null, and then use it in all such places. >=20 > > + return NULL; > > + } > > + > > + /* Create RCU QSBR variable */ > > + size =3D rte_rcu_qsbr_get_memsize(max_threads); > > + qsbr =3D rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE); > > + if (qsbr =3D=3D NULL) { > > + CDEV_LOG_ERR("Failed to allocate memory for RCU > on " > > + "dev=3D%d, queue_pair_id=3D%d", dev_id, qp_id); > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + rte_errno =3D ENOMEM; > > + rte_free(list); > > + rte_free(dev->enq_cbs); > > + dev->enq_cbs[qp_id] =3D NULL; > > + return NULL; > > + } > > + > > + if (rte_rcu_qsbr_init(qsbr, max_threads)) { > > + CDEV_LOG_ERR("Failed to initialize for RCU on " > > + "dev=3D%d, queue_pair_id=3D%d", dev_id, qp_id); > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + rte_free(qsbr); > > + rte_free(list); > > + rte_free(dev->enq_cbs); > > + dev->enq_cbs[qp_id] =3D NULL; > > + return NULL; > > + } > > + > > + dev->enq_cbs[qp_id] =3D list; > > + list->qsbr =3D qsbr; > > + } > > + > > + cb =3D rte_zmalloc(NULL, sizeof(*cb), 0); > > + if (cb =3D=3D NULL) { > > + CDEV_LOG_ERR("Failed to allocate memory for callback on " > > + "dev=3D%d, queue_pair_id=3D%d", dev_id, qp_id); > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + rte_errno =3D ENOMEM; > > + return NULL; > > + } > > + > > + cb->fn =3D cb_fn; > > + cb->arg =3D cb_arg; > > + > > + /* Add the callbacks in fifo order. */ > > + list =3D dev->enq_cbs[qp_id]; > > + tail =3D list->next; > > + if (tail) { > > + while (tail->next) > > + tail =3D tail->next; > > + tail->next =3D cb; > > + } else > > + list->next =3D cb; > > + > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + > > + return cb; > > +} > > + > > +int > > +rte_cryptodev_remove_enq_callback(uint8_t dev_id, > > + uint16_t qp_id, > > + struct rte_cryptodev_cb *cb) > > +{ > > + struct rte_cryptodev *dev; > > + struct rte_cryptodev_cb **prev_cb, *curr_cb; > > + struct rte_cryptodev_enq_cb_rcu *list; > > + uint16_t qp; > > + int free_mem; > > + int ret; > > + > > + free_mem =3D 1; > > + ret =3D -EINVAL; > > + > > + if (!cb) { > > + CDEV_LOG_ERR("cb is NULL"); > > + return ret; > > + } > > + > > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) { > > + CDEV_LOG_ERR("Invalid dev_id=3D%d", dev_id); > > + return ret; > > + } > > + > > + dev =3D &rte_crypto_devices[dev_id]; > > + if (qp_id >=3D dev->data->nb_queue_pairs) { > > + CDEV_LOG_ERR("Invalid queue_pair_id=3D%d", qp_id); > > + return ret; > > + } > > + > > + list =3D dev->enq_cbs[qp_id]; > > + if (list =3D=3D NULL) { > > + CDEV_LOG_ERR("Callback list is NULL"); > > + return ret; > > + } > > + > > + if (list->qsbr =3D=3D NULL) { > > + CDEV_LOG_ERR("Rcu qsbr is NULL"); > > + return ret; > > + } > > + > > + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock); > > + if (dev->enq_cbs =3D=3D NULL) { > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + return ret; > > + } > > + > > + prev_cb =3D &list->next; > > + for (; *prev_cb !=3D NULL; prev_cb =3D &curr_cb->next) { > > + curr_cb =3D *prev_cb; > > + if (curr_cb =3D=3D cb) { > > + /* Remove the user cb from the callback list. */ > > + *prev_cb =3D curr_cb->next; > > + ret =3D 0; > > + break; > > + } > > + } > > + > > + if (!ret) { > > + /* Call sync with invalid thread id as this is part of > > + * control plane API > > + */ > > + rte_rcu_qsbr_synchronize(list->qsbr, > RTE_QSBR_THRID_INVALID); > > + rte_free(cb); > > + } > > + > > + if (list->next =3D=3D NULL) { > > + rte_free(list->qsbr); >=20 > We can't destroy our sync variable while device is not stopped or destroy= ed. > It can be still used by DP. > Probably the easiest way to deal with it - allocate and initialize enq_cb= s[] and > all related qsbrs at first add_callback and free all that memory only on > dev_destroy(). >=20 > > + rte_free(list); > > + dev->enq_cbs[qp_id] =3D NULL; > > + } > > + > > + for (qp =3D 0; qp < dev->data->nb_queue_pairs; qp++) > > + if (dev->enq_cbs[qp] !=3D NULL) { > > + free_mem =3D 0; > > + break; > > + } > > + > > + if (free_mem) { > > + rte_free(dev->enq_cbs); >=20 > Again, not safe to do here, see above. >=20 > > + dev->enq_cbs =3D NULL; > > + } > > + > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > + > > + return ret; > > +} > > +#endif > > > > int > > rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats > > *stats) diff --git a/lib/librte_cryptodev/rte_cryptodev.h > > b/lib/librte_cryptodev/rte_cryptodev.h > > index 0935fd5..669746d 100644 > > --- a/lib/librte_cryptodev/rte_cryptodev.h > > +++ b/lib/librte_cryptodev/rte_cryptodev.h > > @@ -23,6 +23,7 @@ > > #include "rte_dev.h" > > #include > > #include > > +#include > > > > #include "rte_cryptodev_trace_fp.h" > > > > @@ -522,6 +523,34 @@ struct rte_cryptodev_qp_conf { > > /**< The mempool for creating sess private data in sessionless mode > > */ }; > > > > +#ifdef RTE_CRYPTO_CALLBACKS > > +/** > > + * Function type used for pre processing crypto ops when enqueue > > +burst is > > + * called. > > + * > > + * The callback function is called on enqueue burst immediately > > + * before the crypto ops are put onto the hardware queue for processin= g. > > + * > > + * @param dev_id The identifier of the device. > > + * @param qp_id The index of the queue pair in which ops are > > + * to be enqueued for processing. The value > > + * must be in the range [0, nb_queue_pairs - 1] > > + * previously supplied to > > + * *rte_cryptodev_configure*. > > + * @param ops The address of an array of *nb_ops* pointers > > + * to *rte_crypto_op* structures which contain > > + * the crypto operations to be processed. > > + * @param nb_ops The number of operations to process. > > + * @param user_param The arbitrary user parameter passed in by the > > + * application when the callback was originally > > + * registered. > > + * @return The number of ops to be enqueued to the > > + * crypto device. > > + */ > > +typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_= t > qp_id, > > + struct rte_crypto_op **ops, uint16_t nb_ops, void > *user_param); > > +#endif > > + > > /** > > * Typedef for application callback function to be registered by appli= cation > > * software for notification of device events @@ -822,7 +851,6 @@ > > struct rte_cryptodev_config { > > enum rte_cryptodev_event_type event, > > rte_cryptodev_cb_fn cb_fn, void *cb_arg); > > > > - > > typedef uint16_t (*dequeue_pkt_burst_t)(void *qp, > > struct rte_crypto_op **ops, uint16_t nb_ops); > > /**< Dequeue processed packets from queue pair of a device. */ @@ > > -839,6 +867,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp, > > /** Structure to keep track of registered callbacks */ > > TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback); > > > > +#ifdef RTE_CRYPTO_CALLBACKS > > +/** > > + * @internal > > + * Structure used to hold information about the callbacks to be > > +called for a > > + * queue pair on enqueue. > > + */ > > +struct rte_cryptodev_cb { > > + struct rte_cryptodev_cb *next; > > + /** < Pointer to next callback */ > > + rte_cryptodev_callback_fn fn; > > + /** < Pointer to callback function */ > > + void *arg; > > + /** < Pointer to argument */ > > +}; > > + > > +/** > > + * @internal > > + * Structure used to hold information about the RCU for a queue pair. > > + */ > > +struct rte_cryptodev_enq_cb_rcu { > > + struct rte_cryptodev_cb *next; > > + /** < Pointer to next callback */ > > + struct rte_rcu_qsbr *qsbr; > > + /** < RCU QSBR variable per queue pair */ }; #endif > > + > > /** The data structure associated with each crypto device. */ struct > > rte_cryptodev { > > dequeue_pkt_burst_t dequeue_burst; > > @@ -867,6 +922,11 @@ struct rte_cryptodev { > > __extension__ > > uint8_t attached : 1; > > /**< Flag indicating the device is attached */ > > + > > +#ifdef RTE_CRYPTO_CALLBACKS >=20 > I'd *always* reserve space for it. > No matter is RTE_CRYPTO_CALLBACKS defined or not. > To avoid difference in public structure layout. >=20 > > + struct rte_cryptodev_enq_cb_rcu **enq_cbs; >=20 > As I said above, no need for extra level of indirection. >=20 > > + /**< User application callback for pre enqueue processing */ #endif >=20 > As I understand, it is not an ABI breakage - as there are some free space= right > now at the end of struct rte_cryptodev (due to it alignment), but definit= ely need > to update RN. >=20 >=20 > > } __rte_cache_aligned; > > > > void * > > @@ -989,6 +1049,25 @@ struct rte_cryptodev_data { { > > struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; > > > > +#ifdef RTE_CRYPTO_CALLBACKS > > + if (unlikely(dev->enq_cbs !=3D NULL && dev->enq_cbs[qp_id] !=3D NULL)= ) { >=20 > Agree with Honnappa's comment for that piece of code. > Probably need to be something like: >=20 > if (unlikely(dev->enq_cbs !=3D NULL && dev->enq_cbs[qp_id].next !=3D NULL= ) { > list =3D &dev->enq_cbs[qp_id]; > rte_rcu_qsbr_thread_online(list->qsbr, 0); > for (cb =3D list->next; cb !=3D NULL; cb =3D cb->next) > .... > rte_rcu_qsbr_thread_offline(list->qsbr, 0); } >=20 >=20 > > + struct rte_cryptodev_enq_cb_rcu *list; > > + struct rte_cryptodev_cb *cb; > > + > > + list =3D dev->enq_cbs[qp_id]; > > + cb =3D list->next; > > + rte_rcu_qsbr_thread_online(list->qsbr, 0); > > + > > + do { > > + nb_ops =3D cb->fn(dev_id, qp_id, ops, nb_ops, > > + cb->arg); > > + cb =3D cb->next; > > + } while (cb !=3D NULL); > > + > > + rte_rcu_qsbr_thread_offline(list->qsbr, 0); > > + } > > +#endif > > + > > rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, > nb_ops); > > return (*dev->enqueue_burst)( > > dev->data->queue_pairs[qp_id], ops, nb_ops); @@ - > 1730,6 +1809,78 > > @@ struct rte_crypto_raw_dp_ctx { > > rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx, > > uint32_t n); > > > > +#ifdef RTE_CRYPTO_CALLBACKS > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this API may change without prior notice > > + * > > + * Add a user callback for a given crypto device and queue pair which > > +will be > > + * called on crypto ops enqueue. > > + * > > + * This API configures a function to be called for each burst of > > +crypto ops > > + * received on a given crypto device queue pair. The return value is > > +a pointer > > + * that can be used later to remove the callback using > > + * rte_cryptodev_remove_enq_callback(). > > + * > > + * Multiple functions are called in the order that they are added. > > + * > > + * @param dev_id The identifier of the device. > > + * @param qp_id The index of the queue pair in which ops are > > + * to be enqueued for processing. The value > > + * must be in the range [0, nb_queue_pairs - 1] > > + * previously supplied to > > + * *rte_cryptodev_configure*. > > + * @param cb_fn The callback function > > + * @param cb_arg A generic pointer parameter which will be > passed > > + * to each invocation of the callback function on > > + * this crypto device and queue pair. > > + * > > + * @return > > + * NULL on error. > > + * On success, a pointer value which can later be used to remove the > callback. > > + */ > > + > > +__rte_experimental > > +struct rte_cryptodev_cb * > > +rte_cryptodev_add_enq_callback(uint8_t dev_id, > > + uint16_t qp_id, > > + rte_cryptodev_callback_fn cb_fn, > > + void *cb_arg); > > + > > + > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this API may change without prior notice > > + * > > + * Remove a user callback function for given crypto device and queue p= air. > > + * > > + * This function is used to removed callbacks that were added to a > > +crypto > > + * device queue pair using rte_cryptodev_add_enq_callback(). > > + * > > + * > > + * > > + * @param dev_id The identifier of the device. > > + * @param qp_id The index of the queue pair in which ops are > > + * to be enqueued for processing. The value > > + * must be in the range [0, nb_queue_pairs - 1] > > + * previously supplied to > > + * *rte_cryptodev_configure*. > > + * @param cb Pointer to user supplied callback created via > > + * rte_cryptodev_add_enq_callback(). > > + * > > + * @return > > + * - 0: Success. Callback was removed. > > + * - -EINVAL: The dev_id or the qp_id is out of range, or the callb= ack > > + * is NULL or not found for the crypto device queue pair= . > > + */ > > + > > +__rte_experimental > > +int rte_cryptodev_remove_enq_callback(uint8_t dev_id, > > + uint16_t qp_id, > > + struct rte_cryptodev_cb *cb); > > + > > +#endif > > + > > #ifdef __cplusplus > > } > > #endif > > diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map > > b/lib/librte_cryptodev/rte_cryptodev_version.map > > index 7e4360f..5d8d6b0 100644 > > --- a/lib/librte_cryptodev/rte_cryptodev_version.map > > +++ b/lib/librte_cryptodev/rte_cryptodev_version.map > > @@ -101,6 +101,7 @@ EXPERIMENTAL { > > rte_cryptodev_get_qp_status; > > > > # added in 20.11 > > + rte_cryptodev_add_enq_callback; > > rte_cryptodev_configure_raw_dp_ctx; > > rte_cryptodev_get_raw_dp_ctx_size; > > rte_cryptodev_raw_dequeue; > > @@ -109,4 +110,5 @@ EXPERIMENTAL { > > rte_cryptodev_raw_enqueue; > > rte_cryptodev_raw_enqueue_burst; > > rte_cryptodev_raw_enqueue_done; > > + rte_cryptodev_remove_enq_callback; > > }; > > -- > > 1.9.1