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 435BEA04B5; Fri, 11 Sep 2020 10:33:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 223381C0B9; Fri, 11 Sep 2020 10:33:21 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id BF3C51B75C for ; Fri, 11 Sep 2020 10:33:18 +0200 (CEST) IronPort-SDR: ypoGTcwG/ddLaPZuwDt9UUGUoMbN3VLlFRLHMEC8CwwsmPaE6eYrqShwKEAWRvF/wmV2zF29yi UBI2qsnTFvOw== X-IronPort-AV: E=McAfee;i="6000,8403,9740"; a="220270960" X-IronPort-AV: E=Sophos;i="5.76,414,1592895600"; d="scan'208";a="220270960" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2020 01:33:07 -0700 IronPort-SDR: 0+w17oe/WCfDBBBZgx+YyHeTNVxkUXiA8QUz3Emq0kUzdPWVud3wEQ9VUGtpXdyUDMteyTh5tC gmwzWpJfWAoA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,414,1592895600"; d="scan'208";a="378496771" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga001.jf.intel.com with ESMTP; 11 Sep 2020 01:33:07 -0700 Received: from fmsmsx606.amr.corp.intel.com (10.18.126.86) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 11 Sep 2020 01:33:07 -0700 Received: from fmsmsx108.amr.corp.intel.com (10.18.124.206) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 11 Sep 2020 01:33:07 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 11 Sep 2020 01:33:06 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.170) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 11 Sep 2020 01:33:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PbevWPKkj5WlVNJbwC3FOEd4UnCUDZNgU0Lr4nH1nxlknCSZ6UttNR2shzPFXudKPRZ4a2neibuVYNdBDLIC4GVvcgG0eTjvOy6zo1TiizHVq/WhnH31O53uprP9u7DdJBzR5edA4OhFkAzXodx4/n1KHGUwF5wPgE/yuZ9YyfqIoPQC9XlwkiCOkIp3vbfOTntJaGZ0L5mcAEY9pKijmBzNS02+wuhqy3Tta1RMHj5SzwEj7Gu0FgMXzZX433zCm6KHSG+JQ+qOS3TklkZgyidq1EU2hA7eTm9Qy6HL8eIBsHscs1pKe2xbROyZErRS2m7Xc+myxPcR77k+/t7lfQ== 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=H9lAPhd023akuKlpFZ4/Aaf2l6vl30Bht3P8vQaRs/8=; b=Kc6zU4Ne3GDVi8yNii3qpgPffSHYIpdF2ViyzhDKAR+w+qpr/DI1qOx4d+lgMaVK+O+CNH8UIYwmBnU4z/fWgTTLdmhtg1brgZyUrcS99clpwULFcvT+VZzHyBywWbYLm3eH7q6NXwAp1mo3mCFQ84+BePQIdRB5XjlcjnsSn2enwqi22VowznEjhI4nPisHq7UXRTkVV44Nk9Zo2u+WQtnXjAPbE6phmwHNQcyDa3wwwrDrrtjrEB3uQBb/+IZ8zlUPPqYTlY4yJbpUeHTK6zXPU4Waz2CdGputGnDCaIiaKXvEYy+WVrBKnxYdtndMRRrAYufK0YJHo71URxzhTA== 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=H9lAPhd023akuKlpFZ4/Aaf2l6vl30Bht3P8vQaRs/8=; b=zYaC+acu3t3nj9MvzDbroiX/DrpWbrDVfTGIGBPade+PDCL313+RWfrCTEJ3J75KTcOHI2OuUIQGUPkaRiVAL5u1l6C3FOLOoS7nrAkKhgDkQsURYyL7SiEyBu2db6xqCNWC+NYq1Q3cJu4/JnW/Sw+qhuGxy4qBwbg0kkwDa7Q= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (2603:10b6:300:10c::11) by MW3PR11MB4634.namprd11.prod.outlook.com (2603:10b6:303:54::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Fri, 11 Sep 2020 08:33:04 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::34c5:6550:a098:209f%12]) with mapi id 15.20.3370.017; Fri, 11 Sep 2020 08:33:04 +0000 From: "Gujjar, Abhinandan S" To: Honnappa Nagarahalli , "dev@dpdk.org" CC: "Doherty, Declan" , "jerinj@marvell.com" , "Akhil.goyal@nxp.com" , "Vangati, Narender" , "Ananyev, Konstantin" , nd , nd Thread-Topic: [v2 1/2] cryptodev: support enqueue callback functions Thread-Index: AQHWhsTNpueHJn2Z1E+jIJevuNB9zqlgfJJwgABACuCAAl4IgA== Date: Fri, 11 Sep 2020 08:33:04 +0000 Message-ID: References: <1599549024-195051-1-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: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [103.5.135.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ff3e68f-028a-4ee0-4127-08d8562d4d73 x-ms-traffictypediagnostic: MW3PR11MB4634: 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:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Oz6RyHQdiF6Q4pui4tBmjypWfS668QbFY7yzgPcSpLq9EYQiRN2wyuYJqODd11odZT1avpkiN4zjL1Wo3rhZIONXzoAmo68zQmZ6xe26vnU5uCgUfyv223cfXCPnuNpw3/TNCSEyUPLY4w0JigaWCQC2hqiHf4xoZ8vvKRBPwsWjsZY18LCvNFmZ9k8gO7oxrt6pGLorqqTZb72Sd76G5zyOG2QYGwObx+rVWVgRD2n8EuojeHuoluEMFCHRpJY44MNei31L5C/xE+5YeZQUh0AyMj8Dyrw9k04m//yVsWhJG1jmZifzW9vLT+/WvuzSdx+4xvggZLnqpuiawmzRZA== 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)(376002)(39860400002)(366004)(346002)(136003)(396003)(54906003)(110136005)(316002)(66446008)(33656002)(30864003)(66476007)(55236004)(64756008)(66556008)(86362001)(53546011)(66946007)(71200400001)(76116006)(83380400001)(26005)(8676002)(6506007)(5660300002)(2906002)(52536014)(9686003)(478600001)(186003)(55016002)(4326008)(8936002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 0Hcdt6x9HfPIGZmdQPkqOA6uu/j/z/OLgB4rtL7lCqHoqb+NffvX0cE1J6+VkhLw6cwUxO0ZBesJTGzyDLBb8+MWdW7fEOW0C/6rtNQmuQ/Cd7R7HWZ2sx62ZIwWktVB4G+WR4G9gQIp0zTF60cYIrQ3wC+51gwRbGfC811cr+gmpvEbNWFeqTonIlz0ovGLtWjjX9RYirR3/SpOeulgHAeNZVvXUlHiI0sdyEtwGu3oG0xvRutJaOfBKK05OqP1VGHp9CSwE7HNgwKmJeuxvWXcCMv6vGGCotnWVKpy3chTLBLqCH1PzFM/S0e4UeTPEpipp4cg9NZjfklR7W+hWOsmSUAwOjNHoJKO5W/b0DspNJ6jkRezXo9jyKJ4Db5HGnVi6krW6JGyob2Bf5KJwgCnVWo53NAoDlykHF09+ADDbGtEE0gs4ImaMOqYsjGk5lTdPakqbYn2IINKFnhJLaVkMBnvZgs7AyO0VTB5wbjNfkrMEGWhC+B1Cc9gooPT57d3z8EEMc4azzcr2LgeLTzTXWUPdbXFjMgowNe7oLA7pcaKE2xMcEsmO6raxG7ICcVQrr8H7SLWlhgFWGcVeZNWKX1LDKD+Eo2La3vFN/L7QI4XcwWxeNura8BKo0usneEOh9opAOUxCmRrBEioFA== 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: 4ff3e68f-028a-4ee0-4127-08d8562d4d73 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 08:33:04.3392 (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: PR+9AF8aAEaIpmkbkuqUhNDD5Yho/QIrS2zVpts4PrK8fqUMllu324qJFzVHeZfmFfA0awrWhWJJ8zwoopZQp/guK1G5rJKSieB2ofTH1Cg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4634 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [v2 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" > -----Original Message----- > From: Honnappa Nagarahalli > Sent: Thursday, September 10, 2020 4:19 AM > To: Gujjar, Abhinandan S ; dev@dpdk.org > Cc: Doherty, Declan ; jerinj@marvell.com; > Akhil.goyal@nxp.com; Vangati, Narender ; > Ananyev, Konstantin ; nd ; > Honnappa Nagarahalli ; nd > > Subject: RE: [v2 1/2] cryptodev: support enqueue callback functions >=20 > >=20 > > > > > > In an eventdev world, multiple workers (with ordered queue) will be > > > working on IPsec ESP processing. The ESP header's sequence number is > > > unique and has to be sequentially incremented in an orderly manner. > > > This rises a need for incrementing sequence number in crypto stage > > > especially in event crypto adapter. By adding a user callback to > > > cryptodev at enqueue burst, the user callback will get executed in > > > the context of event crypto adapter. This helps the application to > > > increment the ESP sequence number atomically and orderly manner. > > > > > > 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. > > > > > > v1->v2: > > > Moved callback related members to the end of cryptodev struct Added > > > support for RCU > > > > > > Signed-off-by: Abhinandan Gujjar > > > --- > > > config/common_base | 1 + > > > lib/librte_cryptodev/Makefile | 2 +- > > > lib/librte_cryptodev/rte_cryptodev.c | 157 > > > +++++++++++++++++++++++++ > > > lib/librte_cryptodev/rte_cryptodev.h | 154 > > > +++++++++++++++++++++++- > > > lib/librte_cryptodev/rte_cryptodev_version.map | 6 + > > > 5 files changed, 318 insertions(+), 2 deletions(-) > > > > > > diff --git a/config/common_base b/config/common_base index > > > fbf0ee7..f5ebde4 100644 > > > --- a/config/common_base > > > +++ b/config/common_base > > > @@ -599,6 +599,7 @@ > > > CONFIG_RTE_LIBRTE_PMD_BBDEV_FPGA_5GNR_FEC=3Dy > > > # > > > CONFIG_RTE_LIBRTE_CRYPTODEV=3Dy > > > CONFIG_RTE_CRYPTO_MAX_DEVS=3D64 > > > +CONFIG_RTE_CRYPTODEV_CALLBACKS=3Dy > > > > > > # > > > # Compile PMD for ARMv8 Crypto device diff --git > > > a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile > > > index > > > 73e77a2..514d552 100644 > > > --- a/lib/librte_cryptodev/Makefile > > > +++ b/lib/librte_cryptodev/Makefile > > > @@ -10,7 +10,7 @@ LIB =3D librte_cryptodev.a CFLAGS +=3D -O3 CFLAGS= +=3D > > > $(WERROR_FLAGS) LDLIBS +=3D -lrte_eal -lrte_mempool -lrte_ring > > > -lrte_mbuf -LDLIBS +=3D -lrte_kvargs > > > +LDLIBS +=3D -lrte_kvargs -lrte_rcu > > > > > > # library source files > > > SRCS-y +=3D rte_cryptodev.c rte_cryptodev_pmd.c > > > cryptodev_trace_points.c diff --git > > > a/lib/librte_cryptodev/rte_cryptodev.c > > > b/lib/librte_cryptodev/rte_cryptodev.c > > > index 1dd795b..2fb3e35 100644 > > > --- a/lib/librte_cryptodev/rte_cryptodev.c > > > +++ b/lib/librte_cryptodev/rte_cryptodev.c > > > @@ -38,6 +38,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "rte_crypto.h" > > > #include "rte_cryptodev.h" > > > @@ -499,6 +500,10 @@ struct > > > rte_cryptodev_sym_session_pool_private_data { > > > return 0; > > > } > > > > > > +#ifdef RTE_CRYPTODEV_CALLBACKS > > > +/* spinlock for crypto device enq callbacks */ static > > > +rte_spinlock_t rte_cryptodev_enq_cb_lock =3D > > > +RTE_SPINLOCK_INITIALIZER; #endif > Are we claiming the APIs to be thread safe? Is the spinlock required? Yes. E.g. without spinlock, two threads can still try to add callbacks simu= ltaneously. =20 >=20 > > > > > > const char * > > > rte_cryptodev_get_feature_name(uint64_t flag) @@ -1449,6 +1454,158 > > @@ > > > struct rte_cryptodev * > > > rte_spinlock_unlock(&rte_cryptodev_cb_lock); > > > } > > > > > > +#ifdef RTE_CRYPTODEV_CALLBACKS > > > +int > > > +rte_cryptodev_rcu_qsbr_add(uint8_t dev_id, struct rte_rcu_qsbr > > > +*qsbr) > Suggest moving this API outside of RTE_CRYPTODEV_CALLBACKS as it can be > used for other RCU related features in the future. ok >=20 > > > +{ > > > + > > > + struct rte_cryptodev *dev; > > > + > > > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) { > > > + CDEV_LOG_ERR("Invalid dev_id=3D%" PRIu8, dev_id); > > > + return -EINVAL; > > > + } > > > + > > > + dev =3D &rte_crypto_devices[dev_id]; > > > + dev->qsbr =3D qsbr; > > > + return 0; > > > +} > > > + > > > +struct rte_cryptodev_enq_callback * > > > +rte_cryptodev_add_enq_callback(uint8_t dev_id, > > > + uint16_t qp_id, > > > + rte_cryptodev_enq_cb_fn cb_fn, > > > + void *cb_arg) > > > +{ > > > + struct rte_cryptodev *dev; > > > + struct rte_cryptodev_enq_callback *cb, *tail; > > > + > > > + if (!cb_fn) > > > + return NULL; > > > + > > > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) { > > > + CDEV_LOG_ERR("Invalid dev_id=3D%" PRIu8, 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; > > > + } > > > + > > > + 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_errno =3D ENOMEM; > > > + return NULL; > > > + } > > > + > > > + cb->fn =3D cb_fn; > > > + cb->arg =3D cb_arg; > > > + > > > + 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_errno =3D ENOMEM; > > > + rte_free(cb); > Add unlock here. ok >=20 > > > + return NULL; > > > + } > > > + } > > > + > > > + /* Add the callbacks in fifo order. */ > > > + tail =3D dev->enq_cbs[qp_id]; > > > + if (tail) { > > > + while (tail->next) > > > + tail =3D tail->next; > > > + tail->next =3D cb; > > > + } else > > > + dev->enq_cbs[qp_id] =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_enq_callback *cb) { > > > + struct rte_cryptodev *dev; > > > + struct rte_cryptodev_enq_callback **prev_cb, *curr_cb; > > > + uint16_t qp; > > > + int free_mem; > > > + int ret; > > > + > > > + free_mem =3D 1; > > > + > > > + if (!cb) { > > > + CDEV_LOG_ERR("cb is NULL"); > > > + return -EINVAL; > > > + } > > > + > > > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) { > > > + CDEV_LOG_ERR("Invalid dev_id=3D%" PRIu8, dev_id); > > > + return -EINVAL; > > > + } > > > + > > > + 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 -EINVAL; > > > + } > > > + > > > + if (!dev->qsbr) { > > > + CDEV_LOG_ERR("Rcu qsbr is NULL"); > > > + return -EINVAL; > > > + } > I see that this check is not done in 'rte_cryptodev_add_enq_callback'. I = think > this is ok, it avoids enforcing an order for API calls. >=20 > > > + > > > + rte_spinlock_lock(&rte_cryptodev_enq_cb_lock); > > > + if (dev->enq_cbs =3D=3D NULL) { > > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > > + return -EINVAL; > > > + } > > > + > > > + prev_cb =3D &dev->enq_cbs[qp_id]; > > > + 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(dev->qsbr, > > > + RTE_QSBR_THRID_INVALID); > > > + rte_free(cb); > > > + } > > > + > Nit, IMO, it is more readable if 'free_mem =3D 1' is moved here. >=20 > > > + 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); > > > + dev->enq_cbs =3D NULL; > > > + } > > > + > > > + rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock); > > > + > > > + return ret; > > > +} > > > +#endif > > > > > > int > > > rte_cryptodev_sym_session_init(uint8_t dev_id, diff --git > > > a/lib/librte_cryptodev/rte_cryptodev.h > > > b/lib/librte_cryptodev/rte_cryptodev.h > > > index 7b3ebc2..2c7a47b 100644 > > > --- a/lib/librte_cryptodev/rte_cryptodev.h > > > +++ b/lib/librte_cryptodev/rte_cryptodev.h > > > @@ -530,6 +530,32 @@ struct rte_cryptodev_qp_conf { }; > > > > > > /** > > > + * 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 > 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_enq_cb_fn)(uint16_t dev_id, > > > +uint16_t > > > qp_id, > > > + struct rte_crypto_op **ops, uint16_t nb_ops, void > > > *user_param); > > > + > > > +/** > > > * Typedef for application callback function to be registered by > application > > > * software for notification of device events > > > * > > > @@ -853,7 +879,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. */ @@ > > > -870,6 > > > +895,17 @@ 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); > > > > > > +/** > > > + * @internal > > > + * Structure used to hold information about the callbacks to be > > > +called for a > > > + * queue pair on enqueue. > > > + */ > > > +struct rte_cryptodev_enq_callback { > > > + struct rte_cryptodev_enq_callback *next; > > > + rte_cryptodev_enq_cb_fn fn; > > > + void *arg; > > > +}; > > > + > > > /** The data structure associated with each crypto device. */ > > > struct rte_cryptodev { > > > dequeue_pkt_burst_t dequeue_burst; @@ -898,6 +934,14 @@ > struct > > > rte_cryptodev { > > > __extension__ > > > uint8_t attached : 1; > > > /**< Flag indicating the device is attached */ > > > + > > > +#ifdef RTE_CRYPTODEV_CALLBACKS > > > + struct rte_cryptodev_enq_callback **enq_cbs; > > > + /**< User application callback for pre enqueue processing */ > > > + > > > + struct rte_rcu_qsbr *qsbr; > Would be good to move this out of RTE_CRYPTODEV_CALLBACKS so that it > can be used for other features in the future. ok >=20 > > > + /** < RCU QSBR variable for rte_cryptodev_enq_callback */ #endif > > > } __rte_cache_aligned; > > > > > > void * > > > @@ -1019,6 +1063,18 @@ struct rte_cryptodev_data { > > > struct rte_crypto_op **ops, uint16_t nb_ops) { > > > struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; > > > +#ifdef RTE_CRYPTODEV_CALLBACKS > > > + if (unlikely(dev->enq_cbs !=3D NULL && dev->enq_cbs[qp_id] !=3D > > > NULL)) { > > > + struct rte_cryptodev_enq_callback *cb =3D > > > + dev->enq_cbs[qp_id]; > > > + > > > + do { > > > + nb_ops =3D cb->fn(dev_id, qp_id, ops, nb_ops, > > > + cb->arg); > > > + cb =3D cb->next; > > > + } while (cb !=3D NULL); > > > + } > > > +#endif > > > > > > rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, > > > nb_ops); > > > return (*dev->enqueue_burst)( > > > @@ -1351,6 +1407,102 @@ struct rte_cryptodev_asym_session * > > > struct rte_cryptodev_sym_session *sess, union rte_crypto_sym_ofs > > > ofs, > > > struct rte_crypto_sym_vec *vec); > > > > > > +#ifdef RTE_CRYPTODEV_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 t= he > > > callback. > > > + */ > > > + > > > +__rte_experimental > > > +struct rte_cryptodev_enq_callback * > > > +rte_cryptodev_add_enq_callback(uint8_t dev_id, > > > + uint16_t qp_id, > > > + rte_cryptodev_enq_cb_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 > pair. > > > + * > > > + * This function is used to removed callbacks that were added to a > > > +crypto > > > + * device queue pair using rte_cryptodev_add_enq_callback(). > > > + * > > > + * Note: The callback expects a RCU QSBR to be configured to > > > +synchronize > > > + * to free the memory. Application is expected to configure RCU > > > +QSBR after > > > + * adding an enqueue callback. > The application could configure RCU QSBR any time before > 'rte_cryptodev_remove_enq_callback' is called. It has no relation to > 'rte_cryptodev_add_enq_callback' Ok. I will update it. >=20 > > > + * > > > + * > > > + * @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 cal= lback > > > + * is NULL or not found for the crypto device queue pa= ir. > Add RCU variable not configured. ok >=20 > > > + */ > > > + > > > +__rte_experimental > > > +int rte_cryptodev_remove_enq_callback(uint8_t dev_id, > > > + uint16_t qp_id, > > > + struct rte_cryptodev_enq_callback *cb); > > > + > > > + > > > +/** > > > + * @warning > > > + * @b EXPERIMENTAL: this API may change without prior notice > > > + * > > > + * Associate RCU QSBR variable with a cryptodev. > > > + * > > > + * This function is used to add RCU QSBR to a crypto device. > > > + * The purpose of RCU is to help multiple threads to synchronize > > > + * with each other before initiating adding/removing callback > > > + * while dataplane threads are running enqueue callbacks. > How about the following to replace the last sentence above? > "RCU is used to safely reclaim the memory shared with the data plane > threads." Sure >=20 > > > + * > > > + * @param dev_id The identifier of the device. > > > + * @param qsr RCU QSBR configuration > ^^^ qsbr ^^^= ^^^^^^^^ 'variable' is a better > choice > > > + * @return > > > + * On success - 0 > > > + * On error - EINVAL. > > > + */ > > > + > > > +__rte_experimental > > > +int rte_cryptodev_rcu_qsbr_add(uint8_t dev_id, struct rte_rcu_qsbr > > > +*qsbr); #endif > > > + > > > #ifdef __cplusplus > > > } > > > #endif > > > diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map > > > b/lib/librte_cryptodev/rte_cryptodev_version.map > > > index 02f6dcf..46de3ca 100644 > > > --- a/lib/librte_cryptodev/rte_cryptodev_version.map > > > +++ b/lib/librte_cryptodev/rte_cryptodev_version.map > > > @@ -64,6 +64,7 @@ DPDK_20.0 { > > > rte_cryptodev_sym_capability_get; > > > }; > > > > > > + > > > EXPERIMENTAL { > > > global: > > > > > > @@ -105,4 +106,9 @@ EXPERIMENTAL { > > > > > > # added in 20.08 > > > rte_cryptodev_get_qp_status; > > > + > > > + # added in 20.11 > > > + rte_cryptodev_add_enq_callback; > > > + rte_cryptodev_remove_enq_callback; > > > + rte_cryptodev_rcu_qsbr_add; > > > }; > > > -- > > > 1.9.1