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 06123A04B0; Wed, 23 Sep 2020 05:26:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AF08A1D8F6; Wed, 23 Sep 2020 05:26:00 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) by dpdk.org (Postfix) with ESMTP id 1BAA81D8F0 for ; Wed, 23 Sep 2020 05:25:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WMmysWcnCreMtSRwmms7ey7WlweQLsKmWkBa9+udrVE=; b=LR+3+eUM8/3iUKM+3KKuk2WN7Saes028ZsxtyYeL5AeCg9olmZEI3sTyU7YM00E2qPK9cuSDrlfJJLd99uevLhIJ1tLqcmNEHeV1AW4EF9LnsQSeNyIzo4hgo6JTGkJ2tAJjXRmXfFI3Fb77d2kOPOTup/86N9OMh1Wto+yeWaU= Received: from AM6PR10CA0034.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:89::47) by VI1PR0802MB2446.eurprd08.prod.outlook.com (2603:10a6:800:ba::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Wed, 23 Sep 2020 03:25:56 +0000 Received: from AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:89:cafe::3) by AM6PR10CA0034.outlook.office365.com (2603:10a6:209:89::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14 via Frontend Transport; Wed, 23 Sep 2020 03:25:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dpdk.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT023.mail.protection.outlook.com (10.152.16.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Wed, 23 Sep 2020 03:25:56 +0000 Received: ("Tessian outbound e8cdb8c6f386:v64"); Wed, 23 Sep 2020 03:25:56 +0000 X-CR-MTA-TID: 64aa7808 Received: from dab80d804adf.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F891AAFB-82EA-4650-9017-825DFA928A90.1; Wed, 23 Sep 2020 03:25:50 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dab80d804adf.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 23 Sep 2020 03:25:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GehcsDPkVjw9teMrdBZAHQXe+jTipF4YFh56CS7lKMED9fjt9+lJ6dXl7F0ZFXLqB8u8e6tV3v2wAhNjXK16drYvOEqKAjxfB5gakzgdllDI/JgSNPWoGFIGAFn8tzWsZhEwW1l7GuiA85IZ2G+4ETo7OzpAvS3eS44LGjmadDaQM1kSJ/ccSs4sRfT1zgwFhB+2UD+GubRbUH+HoIs64b9gFtIBSEua5NSyYyB2rh8IqkRyTyTTRu0AHvNIABiEFwHjax07gHQOl+Jl8pXykqldqCvPJUCKkANsROwOxdgy37DzMqV2McibjohEVk0x1tA3/ZDa7jwWP05JfIEcng== 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=WMmysWcnCreMtSRwmms7ey7WlweQLsKmWkBa9+udrVE=; b=PgfhGRlTEXYw2oGfGs1+r0+BhRSe4SQpc2BGL+KoIYPJ2J8zQOo0iNRK6ntiNlqlzx4IhFHdpm4hxPPwSP/8vfA+PlAh+bhntmxw3oRMb09wmbcvR2wWB5IR+3a9XHDGFHjo/M274fyuH1aK1eHHI3WkeR9s2H1fSzZUbA7yPyZh0tnc3WAirYIBGVyvWyIr8DzDfHMkl7vknP2K/v/WBJmu8CCeWm59szyT88x5MY5KObDyqKGXk5lQaQZGDxd0lnWa6Ghuo0lEedCzsBtI0rWyHdSAWLc8nmf+e5FxNdRrOPrfswLuFNvY/8YqJi6/E0bjaaGnJcaxoEjKNea49A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WMmysWcnCreMtSRwmms7ey7WlweQLsKmWkBa9+udrVE=; b=LR+3+eUM8/3iUKM+3KKuk2WN7Saes028ZsxtyYeL5AeCg9olmZEI3sTyU7YM00E2qPK9cuSDrlfJJLd99uevLhIJ1tLqcmNEHeV1AW4EF9LnsQSeNyIzo4hgo6JTGkJ2tAJjXRmXfFI3Fb77d2kOPOTup/86N9OMh1Wto+yeWaU= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by DBBPR08MB4870.eurprd08.prod.outlook.com (2603:10a6:10:f6::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Wed, 23 Sep 2020 03:25:48 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::7814:9c1:781f:475d]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::7814:9c1:781f:475d%4]) with mapi id 15.20.3412.020; Wed, 23 Sep 2020 03:25:48 +0000 From: Honnappa Nagarahalli To: "Ananyev, Konstantin" , "Gujjar, Abhinandan S" , "dev@dpdk.org" , "Doherty, Declan" CC: "jerinj@marvell.com" , "Akhil.goyal@nxp.com" , "Vangati, Narender" , nd , Honnappa Nagarahalli , nd Thread-Topic: [dpdk-dev] [v2 1/2] cryptodev: support enqueue callback functions Thread-Index: AQHWhsTNpueHJn2Z1E+jIJevuNB9zqlrUBQAgAARrrCAAXx3gIAGGrIAgAAS1QCAAk5BgA== Date: Wed, 23 Sep 2020 03:25:48 +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: x-ts-tracking-id: B66B2F0A9C8487458E8E54DD11A12A8C.0 x-checkrecipientchecked: true Authentication-Results-Original: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [70.112.90.121] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8a200994-9984-4afc-44fa-08d85f706251 x-ms-traffictypediagnostic: DBBPR08MB4870:|VI1PR0802MB2446: x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: +zUJBvHvV+gi8fKNEHG1xblgBw4IAkg4SLEzLMrsr0xT2pdwY78ndEsGF/JDhCbPZMgruP0Fxc8ijpPyRKM/DbVTuzPA4W/tF8ubjPHmTm8pSFFJyyCrWDwR6x0YPxMd92407b71pDC5nk69EQy1vPoJxI3o3pUulknkHd8Gz/6QmKwwjy9XRA2uKxYjB8+Mi/65TU897CLPVxdojwvpTzZWp9V7IGkd32SN1AVYiTgqow73UN28rhQXM5BanftcdVAR771SSkLNTq/GKpLYbKNRiQFbVX8t9G+DlBp2Qdc62wNlYgDFqNSPK3dkVn/tzGD5nTj4dHwwTRxX3Dj53AWl8pBC/gCRluiE8cbBwpB+X/Y//ay13hhHcyBxavHDaqSXEH6WH/BQRrrn5Cv2ta7o68/aOe3kPYiARcj7IRpqTBIOve/yJ9ivEMa83vT9MgGyefLNgNAiG8C8hrwtFA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(396003)(39840400004)(376002)(66946007)(76116006)(66476007)(966005)(64756008)(66446008)(66556008)(26005)(186003)(83380400001)(4326008)(54906003)(33656002)(110136005)(478600001)(8676002)(6506007)(30864003)(5660300002)(9686003)(52536014)(316002)(7696005)(2906002)(86362001)(55016002)(8936002)(71200400001)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4XRvGmfQsva5CQqL2+PC/0Z92EkCSymOVcpCvdGkOp7/GygM6PolSHx9vFLt/LhtKN9cFm4Rvp8C3FFPgt/YFbENzsoJaPXD6hUYJKGjK7gxlmFUPA2yUCRUobPmC23bSo7twhcJDRwf1zHACro5s/IUgFHkK/BDgnaUvd9Sf+XzBVV8TSFhjEPA4xt2/BGPYMOmemkLUzt7JbTBGTJgSxOF8qBpa6btkoyC9TlTSqNSX4m0m4Kac4KxZzafodA9PMBlG5W7qljC0rWfP/1showada+f129LAkgK2sgUF8AzjoK8FYSXRwLVXKKPUeEVAsnQdly8PUI2uQiVt0/LWuOozWumHzjmP0C2/DZHavWv8kS1+N5GvMow3tarmobz/G0Gv5bnjBzo7KF3A6n9x4ry3spqCMMfhPvGPOKI47Adyk7f5Xu5zmKtrbkYzH8cHi53zeaqEnVzdYWZiD6RUjg2AeKkmdf6RFfOAXh9oREymYY3hnMt6ikz5o/fSTrIKDq0E7JpHR5Q8gvj3klL7EXg0jzTssxnXWbMhbQ1qfS48YS6lt2nVKuwDQjgyXe1loqvA/5/Y2dQOcIN7WMxIgxw02EcUHyPZSYaeff4D+BH3UnM6sICs5nHfavjwim2T6/PTb5pmYANiyUrdPoTyQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4870 Original-Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 017e036b-062a-432e-db63-08d85f705d9a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kDKajmSfDRIr+5IE2yPE91Dx13e5Wq7Awa807nuun3wNe7DZC55BUk5TSKqJu1zj8cA/dUhp+zn3c9sSAhgG6N8qGbiIlaFhuXDByZOgSDzigHVWNahqF8FPbPyji0ZCkbHjATDItAsLDzGtIAt9qIDfqiL7W2xPEmonQIMzUFX6vxmQ3HeAkbCYD74Q4+dFEmGXAWaBxxEO696/h778j+D6ELzsUH+NjO8uZxVzeINGXwtEyjKFP6vch+Py+LH1MHoqOgrHtiPdIbVlTLpiXvSarLrZHKbPBfix+heHmtGXd14sReyohoQ/r9Lr7ayNxwZ4yFgY+v43mR4uBZyV2wyrZd4o2skD/EjzUwNAUgG7XNadtyC3WK9WNA2dt9l68jIU14UJ5AVumbsZL1ZeLjhuArG3OWtCjVxgRmsvYThdK/eix9s8HaWyyOCNKOTJN1MPNZJx7doI8mOmp96R7iaHTHSp0jPI0Dj0hdkhS3Y= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(346002)(39840400004)(376002)(396003)(46966005)(5660300002)(4326008)(2906002)(8936002)(336012)(30864003)(9686003)(55016002)(54906003)(8676002)(82310400003)(70206006)(36906005)(70586007)(7696005)(52536014)(33656002)(356005)(316002)(6506007)(966005)(478600001)(26005)(83380400001)(186003)(110136005)(86362001)(47076004)(81166007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 03:25:56.2484 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8a200994-9984-4afc-44fa-08d85f706251 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2446 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" >=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 > > > > > > > > > > > > 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) { > > > > > > + > > > > > > + 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; > > > > > > +} > > > > > > > > > > So if I understand your patch correctly you propose a new > > > > > working model for > > > > > crypto-devs: > > > > > 1. Control-plane has to allocate/setup rcu_qsbr and do > > > > > rte_cryptodev_rcu_qsbr_add(). > > > > > 2. Data-plane has somehow to obtain pointer to that rcu_qsbr and > > > > > wrap > > > > > cryptodev_enqueue() > > > > > with rcu_qsbr_quiescent() or rcu_qsbr_online()/rcu_qsbr_offli= ne(). > > > > Yes. I think, it is not a new model. It is same as RCU integration = with > LPM. > > > > Please refer: https://patches.dpdk.org/cover/73673/ > > > > > > I am talking about new working model for crypto-dev enqueue/dequeue. > > > As I said above now it becomes data-plane thread responsibility to: > > > -somehow to obtain pointer to that rcu_qsbr for each cryptodev it is > using. > > > -call rcu sync functions (quiescent/online/offline) on a regular bas= is. > > It is not on regular basis. When data plane comes up, they report onlin= e. > > They report quiescent when they are done with critical section or share= d > structure. >=20 > I understand that, but it means all existing apps have to be changed that= way. >=20 > > All though, there is some dataplane changes involved here, I don't thin= k, it > is major. >=20 > I still think our goal here should be to make no visible changes to the > dataplane. > I.E. all necessary data-plane changes need to be hidden inside CB invocat= ion > part. Please note that this is being implemented using the memory reclamation fra= mework documented at https://doc.dpdk.org/guides/prog_guide/rcu_lib.html#re= source-reclamation-framework-for-dpdk While using RCU there are couple of trade-offs that applications have to co= nsider: 1) Performance - reporting the quiescent state too often results in perform= ance impact on data plane 2) Amount of outstanding memory to reclaim - reporting less often results i= n more outstanding memory to reclaim Hence, the quiescent state reporting is left to the application. The applic= ation decides how often it reports the quiescent state and has control over= the data plane performance and the outstanding memory to reclaim. When you say "new working model for crypto-dev enqueue/dequeue", 1) are you comparing these with existing crypto-dev enqueue/dequeue APIs? I= f yes, these are new APIs, it is not breaking anything. 2) are you comparing these with existing call back functions in ethdev enqu= eue/dequeue APIs? If yes, agree that this is a new model. But, it is possib= le to support what ethdev supports along with the RCU method used in this p= atch. >=20 > > > > > Note that now data-plane thread would have to do that always - even > > > if there are now callbacks installed for that cryptodev queue right n= ow. > > > All that changes behaviour of existing apps and I presume would > > > reduce adoption of that fature. If I understand this correct, you are talking about a case where in the app= lication might be registering/unregistering multiple times during its lifet= ime. In this case, yes, the application might be reporting the quiescent st= ate even when it has not registered the call backs. But, it has the flexibi= lity to not report it if it implements additional logic. Note that we are assuming that the application has to report quiescent stat= e only for using callback functions. Most probably the application has othe= r requirements to use RCU. Why not support what is done for ethdev call back functions along with prov= iding RCU method?=20 > > There is always trade off involved! > > In the previous patch, you suggested that some lazy app may not free > > up the memory allocated by add cb. For such apps, this patch has sync > > mechanism with some additional cost of CP & DP changes. >=20 > Sigh, it is not about laziness of the app. > The problem with current ethedev cb mechanism and yours V1 (which was > just a clone of it) - CP doesn't know when it is safe after CB removal to= free > related memory. >=20 > > > I still think all this callback mechanism should be totally opaque > > > to data-plane threads - user shouldn't change his app code depending > > > on would some enqueue/dequeue callbacks be installed or not. > > I am not sure, how that can be implemented with existing RCU design. >=20 > As I said below the simplest way - with calling rcu onine/offline inside = CB > invocation block. > That's why I asked you - did you try that approach and what is the perf > numbers? > I presume with no callbacks installed the perf change should be nearly ze= ro. >=20 > > @Honnappa Nagarahalli, Do you have any suggestions? Reporting quiescent state in the call back functions has several disadvanta= ges: 1) it will have performance impacts and the impacts will increase as the nu= mber of data plane threads increase. 2) It will require additional configuration parameters to control how often= the quiescent state is reported to control the performance impact. 3) Does not take advantage of the fact that most probably the application i= s using RCU already 4) There are few difficulties as well, please see below. > > > > > > > > > > > > > > > > > > > That seems quite a big change and I don't think it is acceptable > > > > > for most users. > > > > > From my perspective adding/installing call-backs to the dev has > > > > > to be opaque to the data-plane code. > > > > > Also note that different callbacks can be installed by different > > > > > entities (libs) and might have no idea about each other. > > > > > That's why I thought it would be better to make all this RCU > > > > > stuff internal inside cryptodev: > > > > > hide all this rcu_qsbr allocation/setup inside cryptod > > > > > somehow to > > > obtain pointer to that rcu_qsbr ev init/queue setup > > > > > invoke rcu_qsbr_online()/rcu_qsbr_offline() inside > > > cryptodev_enqueue(). This will bring in the application related information such as the thread I= D into the library. If the same API calls are being made from multiple data= plane threads, you need a way to configure that information to the library= . So, it is better to leave those details for the application to handle. > > > > I have already tried exploring above stuffs. There are too many > constraints. > > > > The changes don't fit in, as per RCU design. > > > > > > Hmm could you be more specific here - what constraints are you > > > referring to? > > > > > > > Moreover, having rcu api under enqueue_burst() will affect the > > > performance. > > > > > > It most likely will. Though my expectation it will affect > > > performance only when some callbacks are installed. My thought here: > > > callback function by itself will affect cryptdev_enqueue performance > > > anyway, > > With existing callback design, I have measured the performance(with > crypto perf test) on xeon. > > It was almost negligible and same was shared with Declan. >=20 > I am asking about different thing: did you try alternate approach I descr= ibed, > that wouldn't require changes in the user data-plane code. >=20 > > That is one of the reasons, I didn't want to add to many stuffs in to t= he > callback. > > The best part of existing design is crypto lib is not much modified. > > The changes are either pushed to CP or DP. > > > > so adding extra overhead for sync is probably ok here. >=20 > I think that extra overhead when callbacks are present is expected and > probably acceptable. > Changes in the upper-layer data-plane code - probably not. >=20 > > > Though for situation when no callbacks are installed - perfomance > > > should be left unaffected (or impact should be as small as possible). > > > > > > > The changes are more on control plane side, which is one time. > > > > The data plane changes are minimal. > > > > > > I still think upper layer data-plane code should stay unaffected > > > (zero changes). > > > > > > > > > > > > > > + > > > > > > +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); > > > > > > + 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; > > > > > > + } > > > > > > + > > > > > > + 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); > > > > > > + } > > > > > > + > > > > > > + for (qp =3D 0; qp < dev->data->nb_queue_pairs; qp++) > > > > > > + if (dev->enq_cbs[qp] !=3D NULL) { > > > > > > > > > > Some reference count (number of callbacks) seems like a better > > > > > approach here. > > > > Ok. > > > > > > > > > > > + 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; > > > > > > + /** < RCU QSBR variable for rte_cryptodev_enq_callback */ > > > > > > > > > > Probably better to have both these fields per queue. > > > > > Space for them can be allocated at dev_configure() or so. > > > > enq_cbs is allocated during callback add. > > > > Unlike ethdev, each cryptodev have their own max queue pair. There > > > > is no > > > macro for that. > > > > I think, single RCU should be good enough, as it has mechanism to > > > > track all > > > its reporting threads. > > > > > > > > > BTW, wouldn't it make sense to have ability to add callback for > > > > > dequeue > > > too? > > > > As mentioned in the commit message, this patch was driven by a > > > requirement. > > > > If required, callback for the dequeue can be added in a separate pa= tch. > > > > > > > > > > > +#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 ad= ded. > > > > > > + * > > > > > > + * @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 re= move > the > > > > > 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. > > > > > > + * > > > > > > + * > > > > > > + * @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 t= he > callback > > > > > > + * is NULL or not found for the crypto device qu= eue pair. > > > > > > + */ > > > > > > + > > > > > > +__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. > > > > > > + * > > > > > > + * @param dev_id The identifier of the device. > > > > > > + * @param qsr RCU QSBR configuration > > > > > > + * @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