From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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" <abhinandan.gujjar@intel.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, "dev@dpdk.org"
 <dev@dpdk.org>
CC: "Doherty, Declan" <declan.doherty@intel.com>, "jerinj@marvell.com"
 <jerinj@marvell.com>, "Akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, "Vangati,
 Narender" <narender.vangati@intel.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, nd <nd@arm.com>, nd <nd@arm.com>
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: <MWHPR11MB183858FC3DA8A113DE27B49AE8240@MWHPR11MB1838.namprd11.prod.outlook.com>
References: <1599549024-195051-1-git-send-email-abhinandan.gujjar@intel.com>
 <MWHPR11MB183855A77FDD31DD6F1FBE04E8260@MWHPR11MB1838.namprd11.prod.outlook.com>
 <DBAPR08MB581479A8A64D1AECF1A5D3B898260@DBAPR08MB5814.eurprd08.prod.outlook.com>
In-Reply-To: <DBAPR08MB581479A8A64D1AECF1A5D3B898260@DBAPR08MB5814.eurprd08.prod.outlook.com>
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: <MW3PR11MB463426FF2DCB9EB5F9C912D2E8240@MW3PR11MB4634.namprd11.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>



> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Thursday, September 10, 2020 4:19 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org
> Cc: Doherty, Declan <declan.doherty@intel.com>; jerinj@marvell.com;
> Akhil.goyal@nxp.com; Vangati, Narender <narender.vangati@intel.com>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; nd <nd@arm.com>;
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; nd
> <nd@arm.com>
> Subject: RE: [v2 1/2] cryptodev: support enqueue callback functions
>=20
> <snip>
>=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 <abhinandan.gujjar@intel.com>
> > > ---
> > >  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 <rte_string_fns.h>
> > >  #include <rte_compat.h>
> > >  #include <rte_function_versioning.h>
> > > +#include <rte_rcu_qsbr.h>
> > >
> > >  #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