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 92EA7A046B for ; Thu, 27 Jun 2019 16:25:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E50328EE; Thu, 27 Jun 2019 16:25:32 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140051.outbound.protection.outlook.com [40.107.14.51]) by dpdk.org (Postfix) with ESMTP id B613F1E20 for ; Thu, 27 Jun 2019 16:25:30 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=QRvl6Qi4pFG3kLffnOYKFpTIpcbC90OaMXCKlXgVmC2h65GJoC4NF+MvfbQsD+gX0/Uf+cHDDsegu03ZYhtxrf+7//zg0wkvClFkDXGPSYtuC8V8UrUSIzKtj+rWC0Ljj4Wpmmlgo+C6xkTB9r0CSFavcACOcjTOdN/Kt1PUdpA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XrgPtvqULTLjgv291P9TDxtCcqQ4I20V2HYK5CsqBGA=; b=WjLBqwwPyOPklSzZ6HZlOE2Av+OvozLDP7smY6LdvgUSPw3FEX4oDciyFpHujoqyulaQbc5P4LKZ/3aHkDL5tQ+snT5BBH3ALmeSAMtJE6d3RU+EaSwP1Db9+KJivFBTrM8+kh0VVpzWqwq3LY+mIbYjZpBUX6Q8ffsD1ZrZLX8= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XrgPtvqULTLjgv291P9TDxtCcqQ4I20V2HYK5CsqBGA=; b=qZgZd/eOHCPnBnZtsAm7xP2uNOHGk4xesyyZEYqkGHQP+X801As7J6MIcqoGvbsKvf+tOB/JEO83hrl/msG89YsWXPKDmidJY9fC3Vsio/kLK57WsAXXpJ+Ep2t6QZXWqDlh0UgNT272Bs1lbJYRhewPg5ZT5qn9imFV1Cd/aJ8= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6669.eurprd04.prod.outlook.com (20.179.235.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 14:25:29 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::a929:3d03:7bb7:d5e0]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::a929:3d03:7bb7:d5e0%7]) with mapi id 15.20.2008.014; Thu, 27 Jun 2019 14:25:29 +0000 From: Akhil Goyal To: Vipin Varghese , "keith.wiles@intel.com" , "dev@dpdk.org" , "pablo.de.lara.guarch@intel.com" , "declan.doherty@intel.com" CC: "sanjay.padubidri@intel.com" Thread-Topic: [PATCH v2 1/2] lib/crypto: add callback handlers for crypto Thread-Index: AQHVH1Xqx3ciaegumUmbVi8UQnTTpqavpREw Date: Thu, 27 Jun 2019 14:25:28 +0000 Message-ID: References: <20190610050352.83349-1-vipin.varghese@intel.com> <20190610063026.89020-1-vipin.varghese@intel.com> In-Reply-To: <20190610063026.89020-1-vipin.varghese@intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c9d34928-c3a9-423e-7af0-08d6fb0b4df5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6669; x-ms-traffictypediagnostic: VE1PR04MB6669: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(136003)(366004)(39860400002)(189003)(199004)(26005)(229853002)(81156014)(486006)(33656002)(476003)(446003)(71190400001)(74316002)(305945005)(76116006)(7736002)(256004)(99286004)(71200400001)(7696005)(66556008)(73956011)(14454004)(64756008)(66946007)(66476007)(2501003)(2906002)(8676002)(81166006)(9686003)(66446008)(478600001)(110136005)(6506007)(68736007)(66066001)(3846002)(6116002)(6436002)(11346002)(316002)(44832011)(186003)(4326008)(2201001)(86362001)(25786009)(5660300002)(52536014)(8936002)(53936002)(6246003)(76176011)(102836004)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6669; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yvEEIx43jI9kr8X4bl+RTeCyjfYT+hgp36mX7ZZFU1ZP0QNYZqvOkosUsPlySZ3Yk5/CaXZUrpd86onN9iz0R14HMtVAlgHQVnDkkfUiLlxx5ElhoHcffK3kYwSn1p7GgiEsG0iVzKH52n2sGzibOGwY7L3Zz28VeUixN7UWR7Y4dNkvX/+c6XDXwViXW8SGTWji5NTSbIR/J1gbWsagYrlCk1wDLhyaS3yZ/51Ss2NJKHxwIqNkSA+ykqpYp1RDylGuwPZXKUxEG4m+puuMkRB0WbvOgQgaP15Y531zp02Z+wx4C/MIG484pdbu7VZWYXN4z0n1wZaAjYw/gz2BvHE3XXG8Hft/RK8hePcTIpdXB/AAezDpNVRlki6TJRNlVCCoBekZxFEnZVfQkIFzE2h7TjiAasSB4JQ1DhljDww= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9d34928-c3a9-423e-7af0-08d6fb0b4df5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 14:25:28.9230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: akhil.goyal@nxp.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6669 Subject: Re: [dpdk-dev] [PATCH v2 1/2] lib/crypto: add callback handlers for crypto 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 Vipin, >=20 > Add callback handlers for enqueue-dequeue operation on crypto > device. The pre-enqueue and post-dequeue are selected on invoke > user registered callback functions. >=20 > Use cases: > - allow user to investigate the contents pre-enqueue. > - allow user to investigate the contents post-dequeue. > - modify pre-enqueue and post-dequeue stage content. > - investigate PMD meta data. >=20 > Signed-off-by: Vipin Varghese > --- [..] > @@ -907,6 +926,19 @@ rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t > qp_id, > nb_ops =3D (*dev->dequeue_burst) > (dev->data->queue_pairs[qp_id], ops, nb_ops); >=20 > +#ifdef RTE_CRYPTODEV_ENQDEQ_CALLBACKS > + struct rte_cryptodev_enqdeq_callback *cb =3D NULL; > + > + TAILQ_FOREACH(cb, &(dev->deq_cbs), next) { > + if (cb->cb_fn =3D=3D NULL) > + continue; > + > + cb->active =3D 1; > + nb_ops =3D cb->cb_fn(dev_id, qp_id, ops, nb_ops, cb->cb_arg); > + cb->active =3D 0; > + } Shouldn't this cb->active be set atomically. Will it be thread safe? There may be multiple threads enqueuing on the same= device. One may be executing while the other finished and set the active to 0, and = may unregister While the some other thread is still executing. One more thing, it would be better to have a debug prints about how many nb= _ops have been Successfully passed through each of the callback. And in the callback, it should be assumed that it will return back just aft= er the first failed ops, so that The application can free the remaining one. This should be documented in th= e callback API. > +#endif > + > return nb_ops; > } >=20