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 7A0E0A04DD; Wed, 21 Oct 2020 21:34:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A5D136CA1; Wed, 21 Oct 2020 21:34:02 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id EFDDC5A8C for ; Wed, 21 Oct 2020 21:34:00 +0200 (CEST) IronPort-SDR: fLZuNImVOlvtNPe7m6xM0ejpoKix91rLcnJ2/F/nJicH4nZyxex7L4xeV1Q2yvl2wVOYBvRppG lSh8gqthbyAw== X-IronPort-AV: E=McAfee;i="6000,8403,9781"; a="146715944" X-IronPort-AV: E=Sophos;i="5.77,402,1596524400"; d="scan'208";a="146715944" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2020 12:33:55 -0700 IronPort-SDR: tpOwnPGHRlS3YyYaLRLUkrPVFQMUlwNNAKasdq5X+dqN31lcDM6PCCz3i+EMZ2XD5gl7sEIjhd UYlGyZUqLEvg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,401,1596524400"; d="scan'208";a="348442787" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by fmsmga004.fm.intel.com with ESMTP; 21 Oct 2020 12:33:54 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) 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; Wed, 21 Oct 2020 12:33:53 -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; Wed, 21 Oct 2020 12:33:53 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.106) 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; Wed, 21 Oct 2020 12:33:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CB+0ywTvT5INsQJu6XqSoQkfVkPLK4ni1hqlOyczUzsF1F2mVIo6/Fn/m/neDkdC+Yz0ipLAmaFxx+d6Yv8U3Oo/f7Vc9iScp+kBhsp+Qro4ADRcn7a7/aRXj3UNUpBS6Bu72FsePiW0ylR+kEO+qm/Lph8lRhxhD8M4wohriefcH48/6rps3RJgnE4PK41H7kin53NCru48g3VtyrmRqYBDpBmmxcj+xFEHjweT6jWwLWJHamjwTKBy0jvS4P1SFGDQlqpz86YqkD1vIFw+XW3odv+Lm8tb2nReoTVu8UeaO/fxl3hrNQ7Ihrj6S53LpdN2VBx4//7DlMXgFIqwsw== 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=1/6Nh/k7p0WHILj4wHtZIBOESh66cTZOEFsZDAZWcxw=; b=b8RQs21hCqNHL0RBKfLCe56R1Ep2/SJnMu2NNfcvzHIOWG0sn2srn4EoRxj1LgXTv+S6QjC6dIWmWb0jXGWzY8xcIUf9sSqvQCDTY+RIV1vKC7bXvZ1iEpleBnv1Lg/N3ezrs1w6p+npVwoSW/MwyfS7ZXjI2jXtQc39qNnW3Ua6bxaA2eM+Wt5kRBY5RN9GI3XEmwZ3nchGcLDV6GTtG8o8bYD7WdjtVBB2P8HDWdYXdaQymfTPH/KdpHIJuh9i4GPkBad3FYd7havye/IyFrtKabeQjV4cKdYR9EfsYtmXti2xi8nzbH0sxdVArD+Mx/rrdPhrSwgJDdyqK7vm/g== 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=1/6Nh/k7p0WHILj4wHtZIBOESh66cTZOEFsZDAZWcxw=; b=f0fEHYETPJM08kIXPMBscRpzin4YoI3w9PoYfttlDz4u6mCT/KislJKy411lvwzUYAm3ti/s3JIwrm+eEYGtN+ie8A8YpxPpBw1w5JsdnzUXgss1wrUm0LHc8ZBIKYO6SSeuiCtQx/q9geQanQvxkt7lIeV20caWxFbDaDR1TMQ= Received: from BYAPR11MB3301.namprd11.prod.outlook.com (2603:10b6:a03:7f::26) by BY5PR11MB4323.namprd11.prod.outlook.com (2603:10b6:a03:1c2::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22; Wed, 21 Oct 2020 19:33:50 +0000 Received: from BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::f5a4:3f6b:ade3:296b]) by BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::f5a4:3f6b:ade3:296b%3]) with mapi id 15.20.3499.018; Wed, 21 Oct 2020 19:33:50 +0000 From: "Ananyev, Konstantin" To: "Gujjar, Abhinandan S" , "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: AQHWptlTtz9qOEjuGE2V+/oAt34ZKKmiXRlg Date: Wed, 21 Oct 2020 19:33:50 +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: <1603076242-41883-2-git-send-email-abhinandan.gujjar@intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 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: [46.7.39.127] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f482c467-facd-4596-f022-08d875f83ca2 x-ms-traffictypediagnostic: BY5PR11MB4323: 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: /QrnUYtd1l3htkTQ5VTPcCOv94FpQH/3NImrlkgCyDeyZ5DHYkAdR/xH7OPkk7ht6RttNwMwwIMg+ZHrHD7lXekMpS5BKh5FSksClqx8x7lOIOEmtnmYxCAbi8zOQK/DInOEYyb54sh6/YU7Zw0CgIS47h0j5VjkIsjDoYcJ+yO2DT/Li8CGMssYUYLpG/FzwhduAjJTayxlJyZ+EacLwK487dSjWeHC5zPU4L0IxAvO4KDgksDpnb6HsD93MaSHvSaJsHKANER5294znBASFJKM87x7f+rx2h4+MUv16PvHK/CjCfygSkrwMxE8soyKQSzaJTLcgIPA7AnV1y5+LA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3301.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(30864003)(71200400001)(8936002)(316002)(83380400001)(7696005)(52536014)(86362001)(6506007)(76116006)(478600001)(55016002)(4326008)(186003)(66446008)(66946007)(66476007)(9686003)(66556008)(8676002)(64756008)(33656002)(5660300002)(26005)(2906002)(54906003)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: wASDTRZ+z1f1w28OBoFgZLeBUWVw80tlF442t0fa+/gwdnUIURijmzM79I4yn0cPFPzOiKKAP8++BoqXxYXZ+CPtgydlJv/bKIAUbGMX2ETYfGG7VMGzB0AjsBwBe0jBfvk7GW1EJs31wNZbp2IPQJSGDK5SbWg+L2hWBYh0TFf/J/OAbyEvGIFjqxxHQuIMlWYTqUpV8OmikGQ+dvhP4pjCgxNIttoy68LgaPdkV6WGU8GhOTI0JAEKJK2ugJgLVV9w8qRyuAIXJ9Bgo/HfT05hQOJiK77pO39NN+WfUNqfrYpsDAK9U/M8yAjEDcfMTJZlMCGRjX4yP5lL+eSdKOnt/RcVSpp9YpuiyXFT58giX2tdG7qF+qlwxxeYqkGx0+qZXVjz++wgqoQhikkYznQyjfZLR6Yw4mrZLFkTY91EuTAtcjMBCpZnZDK6qmrZTDXJY/rC7Zg6EFy8iL4b5F8IcXCAjStnnqeUDTRMn5WmzvrXgBL/keIZp+KrCHkcYYFF/OSJqRnMdvuHuuCHpe+Oybebo/zrwWBuJlyOK84K4sxJXH3DiR9xEJ5BilltsZrtFhH4sLTNOH/Mr/T4kL8WhiP+4Sq8goMS5Y8QAsqcCfu5DpYVHOU2nRwpA+rxUuWFQrAQjfilrMLGOWSKkg== 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: BYAPR11MB3301.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f482c467-facd-4596-f022-08d875f83ca2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 19:33:50.0446 (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: 5i6GQpdqxVhEaTW5W+ObF+cwXXP3di70ORdvr+b1hImy5lFuqL291C5zL7Ou5Fg0/5N5XLGICcBN4lj+Zz3THbq259pvAP0v6HeAUh52Si0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4323 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 Abhinandan, Thanks for the effort, good progress. Though few more comments, see below. > 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. >=20 > 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(-) 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 >=20 > /* compressdev defines */ > #define RTE_COMPRESS_MAX_DEVS 64 > diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meso= n.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; > } >=20 > +#ifdef RTE_CRYPTO_CALLBACKS > +/* spinlock for crypto device enq callbacks */ > +static rte_spinlock_t rte_cryptodev_enq_cb_lock =3D RTE_SPINLOCK_INITIAL= IZER; > +#endif >=20 > const char * > rte_cryptodev_get_feature_name(uint64_t flag) > @@ -1136,6 +1140,203 @@ struct rte_cryptodev * > socket_id); > } >=20 > +#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); 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 act= ual job, and then lock(); ret=3Dactual_job_internal_functio(...); unlock();... > + rte_errno =3D ENOMEM; > + return NULL; > + } > + > + list =3D rte_zmalloc(NULL, sizeof(*list), 0); 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 qu= eue is already properly initialized. Another thing - is there any point for dev->enq_cbs[] to be a an array of p= ointers to rte_cryptodev_enq_cb_rcu? Considering that rte_cryptodev_enq_cb_rcu itself = contains just two pointers inside, I think it enq_cbs can point just to an array of = rte_cryptodev_enq_cb_rcu: struct rte_cryptodev { ... struct rte_cryptodev_enq_cb_rcu *enq_cbs; And you can remove one level of indirection here and in other places. > + 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); 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 fr= ee 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); We can't destroy our sync variable while device is not stopped or destroyed= . It can be still used by DP. Probably the easiest way to deal with it - allocate and initialize enq_cbs[= ] and all=20 related qsbrs at first add_callback and free all that memory only on dev_de= stroy(). > + 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); Again, not safe to do here, see above. > + dev->enq_cbs =3D NULL; > + } > + > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > + > + return ret; > +} > +#endif >=20 > int > rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stat= s) > 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 >=20 > #include "rte_cryptodev_trace_fp.h" >=20 > @@ -522,6 +523,34 @@ struct rte_cryptodev_qp_conf { > /**< The mempool for creating sess private data in sessionless mode */ > }; >=20 > +#ifdef RTE_CRYPTO_CALLBACKS > +/** > + * Function type used for pre processing crypto ops when enqueue burst i= s > + * called. > + * > + * The callback function is called on enqueue burst immediately > + * before the crypto ops are put onto the hardware queue for processing. > + * > + * @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 applica= tion > * 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); >=20 > - > 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); >=20 > +#ifdef RTE_CRYPTO_CALLBACKS > +/** > + * @internal > + * Structure used to hold information about the callbacks to be called f= or 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 I'd *always* reserve space for it. No matter is RTE_CRYPTO_CALLBACKS defined or not. To avoid difference in public structure layout. > + struct rte_cryptodev_enq_cb_rcu **enq_cbs; As I said above, no need for extra level of indirection. > + /**< User application callback for pre enqueue processing */ > +#endif As I understand, it is not an ABI breakage - as there are some free space r= ight now at the end of struct rte_cryptodev (due to it alignment), but definitely ne= ed to update RN. > } __rte_cache_aligned; >=20 > void * > @@ -989,6 +1049,25 @@ struct rte_cryptodev_data { > { > struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; >=20 > +#ifdef RTE_CRYPTO_CALLBACKS > + if (unlikely(dev->enq_cbs !=3D NULL && dev->enq_cbs[qp_id] !=3D NULL)) = { Agree with Honnappa's comment for that piece of code. Probably need to be something like: 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 } > + 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); >=20 > +#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 wi= ll 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 p= ointer > + * 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 c= allback. > + */ > + > +__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 pai= r. > + * > + * This function is used to removed callbacks that were added to a crypt= o > + * 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 callbac= k > + * 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; >=20 > # 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