From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BFE3BA0C56; Wed, 8 Sep 2021 12:50:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A938D4117B; Wed, 8 Sep 2021 12:50:32 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id 155524115D for ; Wed, 8 Sep 2021 12:50:30 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1889TPvh030826; Wed, 8 Sep 2021 03:50:24 -0700 Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2109.outbound.protection.outlook.com [104.47.70.109]) by mx0a-0016f401.pphosted.com with ESMTP id 3axtka88su-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Sep 2021 03:50:24 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jwS/7WEs9EVKTumjSJ8ENYRpugGOdQ+w4s4PUpDdXCfMUJWGjRX5RNZJzqeR+9RRkw2PmZ3FpYJ2AsnsyKSEmlaUqLpJiZ7Ev8hrMqLM/FNzLIZBgFqZXVPpsr0roGXz1QRyGHkGDzucUPSell4O1/AJpq7YKQMgqp9KkaagNevWjdS0FzKgPg1UcL5DTo8u9jd1vMWa7iooBEn1kPBllm25RoRPbMyoB85VYhidbvrWksWNDxXKvftMf+uMGfINUuublfbue5OS8kW5YLWWFz9vtpQcTVSrXa3CkPYZ55jLMz3kjh+bE53sHcv4vW2jeI0ioJ5eDrXdYZp1SFNP7Q== 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; bh=+6vjeAWo57v/YNQw6ANGjrEXAHgFa4FXKONa3xrmn4w=; b=VssRRKoQ6ywOQ248cOtI/ANrKgQDCYTEbGRHndDbfP8DzduYOf/DwsX0MqiaPz3hhVJF4W2vbrzR24HQm90n7Pn0Jo/NjxC+3ckBIL+Nb3PPdovt5I9UmAEOAxdm66WzykiPvvUVMjG5pVFwM/be8tdhZcsCYpLrU9hh+UGNpLEdANbaOnTZfwLCsF0y2Y8yMFsdYaAN3ZxpjcYrL7IDpHpUiBAgadGcLp9VGm9tTHhOjRgNRhxd9te5m0CE8Zcv6LqM2fUDD9buBSIegaKuklkHnojf4hH4CujRzv73We5RHwQ0dvSsvcg19F8aTOKn8A8MwQP2j7n2Uc4D9vy8hA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+6vjeAWo57v/YNQw6ANGjrEXAHgFa4FXKONa3xrmn4w=; b=W9pYKkMQbqnVBm24cIj9zbHB1DuvOMGf+KLLGJzutjJvr0sE7zrK603Xr3X/qNu/Yj9fMm9npaCkDCktBHZQbLVS8zD3exSYdTl+P+BXS61E/hSEEid8zBDXh5rd2mCSteHo3aoGse16MJ2Z+i7lNaCoGXeS3t0pF/iuPjO+670= Received: from PH0PR18MB4672.namprd18.prod.outlook.com (2603:10b6:510:c9::16) by PH0PR18MB4782.namprd18.prod.outlook.com (2603:10b6:510:cb::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14; Wed, 8 Sep 2021 10:50:20 +0000 Received: from PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::85aa:3d01:94f6:984]) by PH0PR18MB4672.namprd18.prod.outlook.com ([fe80::85aa:3d01:94f6:984%4]) with mapi id 15.20.4500.015; Wed, 8 Sep 2021 10:50:20 +0000 From: Anoob Joseph To: Akhil Goyal CC: "radu.nicolau@intel.com" , "declan.doherty@intel.com" , "hemant.agrawal@nxp.com" , "matan@nvidia.com" , "konstantin.ananyev@intel.com" , "thomas@monjalon.net" , "roy.fan.zhang@intel.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" , "ajit.khaparde@broadcom.com" , "pablo.de.lara.guarch@intel.com" , "fiona.trahe@intel.com" , Ankur Dwivedi , Michael Shamis , Nagadheeraj Rottela , "jianjay.zhou@huawei.com" , "dev@dpdk.org" , Jerin Jacob Kollanukkaran , Akhil Goyal Thread-Topic: [PATCH 1/8] cryptodev: separate out internal structures Thread-Index: AQHXnNSmDIdA83iewUONlvD3swFCiquaACOA Date: Wed, 8 Sep 2021 10:50:20 +0000 Message-ID: References: <20210829125139.2173235-1-gakhil@marvell.com> <20210829125139.2173235-2-gakhil@marvell.com> In-Reply-To: <20210829125139.2173235-2-gakhil@marvell.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5be2346b-5866-43df-1240-08d972b6741c x-ms-traffictypediagnostic: PH0PR18MB4782: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZWFVK8rTEfkGxyXctrwMx3w2ucV2eAs5Pp0eBrZ0Qib6xI31zbAM606rUR23RGkg0tYii/xPZ6DveaqObcFIfWyEfSlQNrR2Uhv4NeY+Td1imgq9++07OtKU99shUglbxCPRKcZGuGevhAO+MhPyT8Y6xq9zUNM+NTebY9clts6nPRpxHp6msMJN1WynyRtkUo/JkQMpFQYkoHhrsMMvq+fuqhPEqpve75sEbu/nWt9jWuLHD3/rrjGKXNj9bOpJLYEKATm1k8UGvWblN28GRO9bTeNPtsGylxn4cwX/IBBTahcBF61jaXHw5zDIo0LFoZ7u4xoW229xpiBTYRw/d34YIT9iYKPR1Dj59c4jq5Nl2PnnG4NEBJAWMtlZWWJ0gqCGtkHbSSU4K8zUmnxjbeQ1mgdjlnoHZML2s7HJTZEtj6WT7AYbX9oa2eXqGbECHtJ+g1HoSb65NU7k2j6QFTHB8jsEukMsgL/aWD24PZIfdNsAMal7D++hr4AEHW5SrLP4e6+21zjefVWV/CnvCWHtoaJTqN9z1sluMJB2waFEsurKJ7JWWjc0pbcIk9J/loY2/vCR1Uy4r0wDWGPPuc1CWtAiHymakWyCpCwwcVL7xJaRQl39BGpYSXHlF0XcBy9d3VuVv/ZH+EaEsr3YXYgySn1B3HOvMsfoIrAIs2SjhUXSmZtWyeakkr7GLyE2yoIAjTXlF53lHfhGWUujpw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4672.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(366004)(396003)(136003)(8676002)(2906002)(8936002)(7696005)(107886003)(6862004)(64756008)(6506007)(66946007)(478600001)(9686003)(66476007)(33656002)(66446008)(55016002)(71200400001)(316002)(66556008)(122000001)(54906003)(52536014)(38100700002)(30864003)(4326008)(7416002)(26005)(186003)(6636002)(38070700005)(83380400001)(76116006)(5660300002)(86362001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/Teo4NHF/AnFmeE6td3LDZVyePg8p8zwW/ruyqDN5RQb50wcAi5Fals5gCDn?= =?us-ascii?Q?Hf3eH3zL93u9iOQuKrXanQnLfncvK0qUN4ZhloWo9gcTfaSR3bDNPW6N/93l?= =?us-ascii?Q?tWQy5A0RO52Nq7NcrBe5zS9gF0Xx+OBn/WT9dCN1iySyuNA6GwENMFD79HKV?= =?us-ascii?Q?GT5cdLeXD7CNAogBIiFanMxgCefLBzKaXmTjlGU7vf1UQXToD0Re9VE7BCP+?= =?us-ascii?Q?KQhcn6nNn9ZVL9yzOuK9VTrtvQO587dfNpasherOmBDwrdv1sJuo7gXINLcZ?= =?us-ascii?Q?UL2AD1T4lAJHj5JQea99+mkYzwdg/KHiC0fMXD22J/6gWhAkks3s6/s25xC1?= =?us-ascii?Q?spl0dWnlOzh/UPVxVCw1D962x9REEa9r+83rVRBlX7ZVvLY+oa1bS19+LPv/?= =?us-ascii?Q?b2jPVuoTgVaC9ye6cFMzNzrgI6hDLtk6OQb5DfjYiuSqL9VlnEAux94izUrk?= =?us-ascii?Q?t1+fIMmc9mNSOqduwrlGDhQ3XWLayTWf+wL1CZmkiqdJXX9vwG1Tmm/QA5P9?= =?us-ascii?Q?Hi7R3LlLI5D8rJ4TmiCwfKkwIPzxHRxCjtBWOu4XEV7nSJxNXc0k8gSwJOhu?= =?us-ascii?Q?0/+B0FrRCNcGkylQp5Ko9JlmdhdjG/6SqzIjdv0QJYJUpj08EDfCDygRvzaR?= =?us-ascii?Q?sMRjdHFxg9CwzV1IGY5eKRf78/tZfzuUfKh0ZWv+evLy+CTDcbzfQxmbPI0s?= =?us-ascii?Q?jMuKH5xQ2999fNh/BnKCz4SOVWEVFV0rDj9Mik6UMr9R//ejlCTDm7lia4t+?= =?us-ascii?Q?fxTscsWdnxLXWGaicNOg96/SU4Y6OqFvT/D48BNtTC5AO9Dk4nKkDlstRmCl?= =?us-ascii?Q?OMh791bBHJn1rEGriP5/aGFE5IsRz4xuhovfwWu/RE1cJ9oMMW26mibRUvCC?= =?us-ascii?Q?im6ck0Y1td3RpMsi8IYarvVEnNmmM05dCdCeAfQkIl1pny1jqJF1kIbydpqn?= =?us-ascii?Q?NAfe4OxDthCnC570josAOpLtohW2d9nNzt7Q6SiACDjevNYcie/beTlRi4p/?= =?us-ascii?Q?9nmK7T2GCBeDvMoxBuaB7weP1533sRuUsh+4npBrkQNL9jwfKzr6850v/c0r?= =?us-ascii?Q?e/hj6GdKgbI/iXbORgjJEnzb/RZx5RHX1b36nvYMRX6oqSi8iK4R5Vtw3ppe?= =?us-ascii?Q?RdflQ9L5ujN0HlY8qAFXg+v6nS4JdufcIZ/7yyKvysoS7ZoxcPTvw/mPR4ua?= =?us-ascii?Q?sXSdqGSS6aBC7A5IUFsq3mPc/WYJcgbxCAiwl8Ikr198n8FVdsUzEnx90+TL?= =?us-ascii?Q?JnRvdgfK8qwQi8Zkqe9cfW9fnbL8Nlwcgfuv1zjOseNNVt+jrUyFvPE05RgJ?= =?us-ascii?Q?+9lyxqsw3s6Efyzi6u1Kdnzq?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4672.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5be2346b-5866-43df-1240-08d972b6741c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2021 10:50:20.5504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mfOkZo+8yQ/5OtkqY+MNtDobGTC2GOiBLJ0o9b6f6WfuuE0HlQUZ225QzRuBpYc49FvJGRvKuRIYWkIgjmV8NA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR18MB4782 X-Proofpoint-GUID: 98wdXsYwpWWmj7MN5iVstE2hN81xnpRb X-Proofpoint-ORIG-GUID: 98wdXsYwpWWmj7MN5iVstE2hN81xnpRb X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-08_05,2021-09-07_02,2020-04-07_01 Subject: Re: [dpdk-dev] [PATCH 1/8] cryptodev: separate out internal structures X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Akhil, Please see inline. Thanks, Anoob > Subject: [PATCH 1/8] cryptodev: separate out internal structures >=20 > A new header file rte_cryptodev_core.h is added and all internal data > structures which need not be exposed directly to application are moved to > this file. These structures are mostly used by drivers, but they need to = be in > the public header file as they are accessed by datapath inline functions = for > performance reasons. >=20 > Signed-off-by: Akhil Goyal > --- > lib/cryptodev/cryptodev_pmd.h | 6 - > lib/cryptodev/meson.build | 4 +- > lib/cryptodev/rte_cryptodev.h | 360 ++++++++++++----------------- > lib/cryptodev/rte_cryptodev_core.h | 100 ++++++++ > 4 files changed, 245 insertions(+), 225 deletions(-) create mode 100644 > lib/cryptodev/rte_cryptodev_core.h >=20 > diff --git a/lib/cryptodev/cryptodev_pmd.h > b/lib/cryptodev/cryptodev_pmd.h index ec7bb82be8..f775ba6beb 100644 > --- a/lib/cryptodev/cryptodev_pmd.h > +++ b/lib/cryptodev/cryptodev_pmd.h > @@ -96,12 +96,6 @@ __rte_internal > struct rte_cryptodev * > rte_cryptodev_pmd_get_named_dev(const char *name); >=20 > -/** > - * The pool of rte_cryptodev structures. > - */ > -extern struct rte_cryptodev *rte_cryptodevs; > - > - > /** > * Definitions of all functions exported by a driver through the > * the generic structure of type *crypto_dev_ops* supplied in the diff -= -git > a/lib/cryptodev/meson.build b/lib/cryptodev/meson.build index > 735935df4a..f32cc62a78 100644 > --- a/lib/cryptodev/meson.build > +++ b/lib/cryptodev/meson.build > @@ -14,7 +14,9 @@ headers =3D files( > 'rte_crypto_sym.h', > 'rte_crypto_asym.h', > ) > - > +indirect_headers +=3D files( > + 'rte_cryptodev_core.h', > +) > driver_sdk_headers +=3D files( > 'cryptodev_pmd.h', > ) > diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.= h > index 33aac44446..3d99dd1cf5 100644 > --- a/lib/cryptodev/rte_cryptodev.h > +++ b/lib/cryptodev/rte_cryptodev.h > @@ -861,17 +861,6 @@ rte_cryptodev_callback_unregister(uint8_t dev_id, > enum rte_cryptodev_event_type event, > rte_cryptodev_cb_fn cb_fn, void *cb_arg); >=20 > -typedef uint16_t (*dequeue_pkt_burst_t)(void *qp, > - struct rte_crypto_op **ops, uint16_t nb_ops); > -/**< Dequeue processed packets from queue pair of a device. */ > - > -typedef uint16_t (*enqueue_pkt_burst_t)(void *qp, > - struct rte_crypto_op **ops, uint16_t nb_ops); > -/**< Enqueue packets for processing on queue pair of a device. */ > - > - > - > - > struct rte_cryptodev_callback; >=20 > /** Structure to keep track of registered callbacks */ @@ -901,216 +890,= 9 > @@ struct rte_cryptodev_cb_rcu { > /**< RCU QSBR variable per queue pair */ }; >=20 > -/** The data structure associated with each crypto device. */ -struct > rte_cryptodev { > - dequeue_pkt_burst_t dequeue_burst; > - /**< Pointer to PMD receive function. */ > - enqueue_pkt_burst_t enqueue_burst; > - /**< Pointer to PMD transmit function. */ > - > - struct rte_cryptodev_data *data; > - /**< Pointer to device data */ > - struct rte_cryptodev_ops *dev_ops; > - /**< Functions exported by PMD */ > - uint64_t feature_flags; > - /**< Feature flags exposes HW/SW features for the given device */ > - struct rte_device *device; > - /**< Backing device */ > - > - uint8_t driver_id; > - /**< Crypto driver identifier*/ > - > - struct rte_cryptodev_cb_list link_intr_cbs; > - /**< User application callback for interrupts if present */ > - > - void *security_ctx; > - /**< Context for security ops */ > - > - __extension__ > - uint8_t attached : 1; > - /**< Flag indicating the device is attached */ > - > - struct rte_cryptodev_cb_rcu *enq_cbs; > - /**< User application callback for pre enqueue processing */ > - > - struct rte_cryptodev_cb_rcu *deq_cbs; > - /**< User application callback for post dequeue processing */ > -} __rte_cache_aligned; > - > void * > rte_cryptodev_get_sec_ctx(uint8_t dev_id); >=20 > -/** > - * > - * The data part, with no function pointers, associated with each device= . > - * > - * This structure is safe to place in shared memory to be common among > - * different processes in a multi-process configuration. > - */ > -struct rte_cryptodev_data { > - uint8_t dev_id; > - /**< Device ID for this instance */ > - uint8_t socket_id; > - /**< Socket ID where memory is allocated */ > - char name[RTE_CRYPTODEV_NAME_MAX_LEN]; > - /**< Unique identifier name */ > - > - __extension__ > - uint8_t dev_started : 1; > - /**< Device state: STARTED(1)/STOPPED(0) */ > - > - struct rte_mempool *session_pool; > - /**< Session memory pool */ > - void **queue_pairs; > - /**< Array of pointers to queue pairs. */ > - uint16_t nb_queue_pairs; > - /**< Number of device queue pairs. */ > - > - void *dev_private; > - /**< PMD-specific private data */ > -} __rte_cache_aligned; > - > -extern struct rte_cryptodev *rte_cryptodevs; > -/** > - * > - * Dequeue a burst of processed crypto operations from a queue on the > crypto > - * device. The dequeued operation are stored in *rte_crypto_op* > structures > - * whose pointers are supplied in the *ops* array. > - * > - * The rte_cryptodev_dequeue_burst() function returns the number of ops > - * actually dequeued, which is the number of *rte_crypto_op* data > structures > - * effectively supplied into the *ops* array. > - * > - * A return value equal to *nb_ops* indicates that the queue contained > - * at least *nb_ops* operations, and this is likely to signify that othe= r > - * processed operations remain in the devices output queue. Applications > - * implementing a "retrieve as many processed operations as possible" > policy > - * can check this specific case and keep invoking the > - * rte_cryptodev_dequeue_burst() function until a value less than > - * *nb_ops* is returned. > - * > - * The rte_cryptodev_dequeue_burst() function does not provide any error > - * notification to avoid the corresponding overhead. > - * > - * @param dev_id The symmetric crypto device identifier > - * @param qp_id The index of the queue pair from which to > - * retrieve processed packets. The value must > be > - * in the range [0, nb_queue_pair - 1] > previously > - * supplied to rte_cryptodev_configure(). > - * @param ops The address of an array of pointers to > - * *rte_crypto_op* structures that must be > - * large enough to store *nb_ops* pointers in > it. > - * @param nb_ops The maximum number of operations to > dequeue. > - * > - * @return > - * - The number of operations actually dequeued, which is the number > - * of pointers to *rte_crypto_op* structures effectively supplied to t= he > - * *ops* array. > - */ > -static inline uint16_t > -rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, > - struct rte_crypto_op **ops, uint16_t nb_ops) > -{ > - struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; > - > - rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops, > nb_ops); > - nb_ops =3D (*dev->dequeue_burst) > - (dev->data->queue_pairs[qp_id], ops, nb_ops); > -#ifdef RTE_CRYPTO_CALLBACKS > - if (unlikely(dev->deq_cbs !=3D NULL)) { > - struct rte_cryptodev_cb_rcu *list; > - struct rte_cryptodev_cb *cb; > - > - /* __ATOMIC_RELEASE memory order was used when the > - * call back was inserted into the list. > - * Since there is a clear dependency between loading > - * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory > order is > - * not required. > - */ > - list =3D &dev->deq_cbs[qp_id]; > - rte_rcu_qsbr_thread_online(list->qsbr, 0); > - cb =3D __atomic_load_n(&list->next, __ATOMIC_RELAXED); > - > - while (cb !=3D NULL) { > - nb_ops =3D cb->fn(dev_id, qp_id, ops, nb_ops, > - cb->arg); > - cb =3D cb->next; > - }; > - > - rte_rcu_qsbr_thread_offline(list->qsbr, 0); > - } > -#endif > - return nb_ops; > -} > - > -/** > - * Enqueue a burst of operations for processing on a crypto device. > - * > - * The rte_cryptodev_enqueue_burst() function is invoked to place > - * crypto operations on the queue *qp_id* of the device designated by > - * its *dev_id*. > - * > - * The *nb_ops* parameter is the number of operations to process which > are > - * supplied in the *ops* array of *rte_crypto_op* structures. > - * > - * The rte_cryptodev_enqueue_burst() function returns the number of > - * operations it actually enqueued for processing. A return value equal = to > - * *nb_ops* means that all packets have been enqueued. > - * > - * @param dev_id The identifier of the device. > - * @param qp_id The index of the queue pair which packets > 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. > - * > - * @return > - * The number of operations actually enqueued on the crypto device. The > return > - * value can be less than the value of the *nb_ops* parameter when the > - * crypto devices queue is full or if invalid parameters are specified i= n > - * a *rte_crypto_op*. > - */ > -static inline uint16_t > -rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id, > - struct rte_crypto_op **ops, uint16_t nb_ops) > -{ > - struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; > - > -#ifdef RTE_CRYPTO_CALLBACKS > - if (unlikely(dev->enq_cbs !=3D NULL)) { > - struct rte_cryptodev_cb_rcu *list; > - struct rte_cryptodev_cb *cb; > - > - /* __ATOMIC_RELEASE memory order was used when the > - * call back was inserted into the list. > - * Since there is a clear dependency between loading > - * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory > order is > - * not required. > - */ > - list =3D &dev->enq_cbs[qp_id]; > - rte_rcu_qsbr_thread_online(list->qsbr, 0); > - cb =3D __atomic_load_n(&list->next, __ATOMIC_RELAXED); > - > - while (cb !=3D NULL) { > - nb_ops =3D cb->fn(dev_id, qp_id, ops, nb_ops, > - cb->arg); > - cb =3D cb->next; > - }; > - > - rte_rcu_qsbr_thread_offline(list->qsbr, 0); > - } > -#endif > - > - rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, > nb_ops); > - return (*dev->enqueue_burst)( > - dev->data->queue_pairs[qp_id], ops, nb_ops); > -} > - > - > /** Cryptodev symmetric crypto session > * Each session is derived from a fixed xform chain. Therefore each sess= ion > * has a fixed algo, key, op-type, digest_len etc. > @@ -1997,6 +1779,148 @@ int rte_cryptodev_remove_deq_callback(uint8_t > dev_id, > uint16_t qp_id, > struct rte_cryptodev_cb *cb); >=20 > +#include [Anoob] Is this intentional? Shouldn't we keep includes together in the top= of the file? =20 > +/** > + * [Anoob] Is there an extra blank line? =20 > + * Dequeue a burst of processed crypto operations from a queue on the > +crypto > + * device. The dequeued operation are stored in *rte_crypto_op* > +structures > + * whose pointers are supplied in the *ops* array. > + * > + * The rte_cryptodev_dequeue_burst() function returns the number of ops > + * actually dequeued, which is the number of *rte_crypto_op* data > +structures > + * effectively supplied into the *ops* array. > + * > + * A return value equal to *nb_ops* indicates that the queue contained > + * at least *nb_ops* operations, and this is likely to signify that > +other > + * processed operations remain in the devices output queue. > +Applications > + * implementing a "retrieve as many processed operations as possible" > +policy > + * can check this specific case and keep invoking the > + * rte_cryptodev_dequeue_burst() function until a value less than > + * *nb_ops* is returned. > + * > + * The rte_cryptodev_dequeue_burst() function does not provide any > +error > + * notification to avoid the corresponding overhead. > + * > + * @param dev_id The symmetric crypto device identifier [Anoob] I do realize this is copied from existing code, but "symmetric" sho= uld not be there in the above string, right? The API is equally applicable = for all cryptodev operations, right? =20 > + * @param qp_id The index of the queue pair from which to > + * retrieve processed packets. The value must > be > + * in the range [0, nb_queue_pair - 1] > previously > + * supplied to rte_cryptodev_configure(). > + * @param ops The address of an array of pointers to > + * *rte_crypto_op* structures that must be > + * large enough to store *nb_ops* pointers in > it. > + * @param nb_ops The maximum number of operations to > dequeue. > + * > + * @return > + * - The number of operations actually dequeued, which is the number > + * of pointers to *rte_crypto_op* structures effectively supplied to t= he > + * *ops* array. > + */ > +static inline uint16_t > +rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, > + struct rte_crypto_op **ops, uint16_t nb_ops) { > + struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; > + > + rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops, > nb_ops); > + nb_ops =3D (*dev->dequeue_burst) > + (dev->data->queue_pairs[qp_id], ops, nb_ops); > #ifdef > +RTE_CRYPTO_CALLBACKS > + if (unlikely(dev->deq_cbs !=3D NULL)) { > + struct rte_cryptodev_cb_rcu *list; > + struct rte_cryptodev_cb *cb; > + > + /* __ATOMIC_RELEASE memory order was used when the > + * call back was inserted into the list. > + * Since there is a clear dependency between loading > + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory > order is > + * not required. > + */ > + list =3D &dev->deq_cbs[qp_id]; > + rte_rcu_qsbr_thread_online(list->qsbr, 0); > + cb =3D __atomic_load_n(&list->next, __ATOMIC_RELAXED); > + > + while (cb !=3D NULL) { > + nb_ops =3D cb->fn(dev_id, qp_id, ops, nb_ops, > + cb->arg); > + cb =3D cb->next; > + }; > + > + rte_rcu_qsbr_thread_offline(list->qsbr, 0); > + } > +#endif > + return nb_ops; > +} > + > +/** > + * Enqueue a burst of operations for processing on a crypto device. > + * > + * The rte_cryptodev_enqueue_burst() function is invoked to place > + * crypto operations on the queue *qp_id* of the device designated by > + * its *dev_id*. > + * > + * The *nb_ops* parameter is the number of operations to process which > +are > + * supplied in the *ops* array of *rte_crypto_op* structures. > + * > + * The rte_cryptodev_enqueue_burst() function returns the number of > + * operations it actually enqueued for processing. A return value equal > +to > + * *nb_ops* means that all packets have been enqueued. > + * > + * @param dev_id The identifier of the device. > + * @param qp_id The index of the queue pair which packets > 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. > + * > + * @return > + * The number of operations actually enqueued on the crypto device. The > +return > + * value can be less than the value of the *nb_ops* parameter when the > + * crypto devices queue is full or if invalid parameters are specified > +in > + * a *rte_crypto_op*. > + */ > +static inline uint16_t > +rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id, > + struct rte_crypto_op **ops, uint16_t nb_ops) { > + struct rte_cryptodev *dev =3D &rte_cryptodevs[dev_id]; > + > +#ifdef RTE_CRYPTO_CALLBACKS > + if (unlikely(dev->enq_cbs !=3D NULL)) { > + struct rte_cryptodev_cb_rcu *list; > + struct rte_cryptodev_cb *cb; > + > + /* __ATOMIC_RELEASE memory order was used when the > + * call back was inserted into the list. > + * Since there is a clear dependency between loading > + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory > order is > + * not required. > + */ > + list =3D &dev->enq_cbs[qp_id]; > + rte_rcu_qsbr_thread_online(list->qsbr, 0); > + cb =3D __atomic_load_n(&list->next, __ATOMIC_RELAXED); > + > + while (cb !=3D NULL) { > + nb_ops =3D cb->fn(dev_id, qp_id, ops, nb_ops, > + cb->arg); > + cb =3D cb->next; > + }; > + > + rte_rcu_qsbr_thread_offline(list->qsbr, 0); > + } > +#endif > + > + rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, > nb_ops); > + return (*dev->enqueue_burst)( > + dev->data->queue_pairs[qp_id], ops, nb_ops); } > + > + [Anoob] Couple of extra blank lines can be removed? =20 > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/cryptodev/rte_cryptodev_core.h > b/lib/cryptodev/rte_cryptodev_core.h > new file mode 100644 > index 0000000000..1633e55889 > --- /dev/null > +++ b/lib/cryptodev/rte_cryptodev_core.h > @@ -0,0 +1,100 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(C) 2021 Marvell. [Anoob] Since the code is mostly a copy from rte_cryptodev.h shouldn't we r= etain original licenses also? =20 > + */ > + > +#ifndef _RTE_CRYPTODEV_CORE_H_ > +#define _RTE_CRYPTODEV_CORE_H_ [Anoob] We are not including any of the dependent headers in this file. So = the caller would be required to include all the dependent headers. Might be= better to include atleast basic required ones (for rte_crypto_op etc). =20 > + > +/** > + * @file > + * > + * RTE Crypto Device internal header. > + * > + * This header contains internal data types. But they are still part of > +the > + * public API because they are used by inline functions in the published= API. > + * > + * Applications should not use these directly. > + * > + */ > + > +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. */ > + > +typedef uint16_t (*enqueue_pkt_burst_t)(void *qp, > + struct rte_crypto_op **ops, uint16_t nb_ops); > +/**< Enqueue packets for processing on queue pair of a device. */ > + > +/** > + * @internal > + * The data part, with no function pointers, associated with each device= . > + * > + * This structure is safe to place in shared memory to be common among > + * different processes in a multi-process configuration. > + */ > +struct rte_cryptodev_data { > + uint8_t dev_id; > + /**< Device ID for this instance */ > + uint8_t socket_id; > + /**< Socket ID where memory is allocated */ > + char name[RTE_CRYPTODEV_NAME_MAX_LEN]; > + /**< Unique identifier name */ > + > + __extension__ > + uint8_t dev_started : 1; > + /**< Device state: STARTED(1)/STOPPED(0) */ > + > + struct rte_mempool *session_pool; > + /**< Session memory pool */ > + void **queue_pairs; > + /**< Array of pointers to queue pairs. */ > + uint16_t nb_queue_pairs; > + /**< Number of device queue pairs. */ > + > + void *dev_private; > + /**< PMD-specific private data */ > +} __rte_cache_aligned; > + > + > +/** @internal The data structure associated with each crypto device. */ > +struct rte_cryptodev { > + dequeue_pkt_burst_t dequeue_burst; > + /**< Pointer to PMD receive function. */ > + enqueue_pkt_burst_t enqueue_burst; > + /**< Pointer to PMD transmit function. */ [Anoob] Transmit & receive are more ethdev specific terminology, right? Why= not enqueue/dequeue itself? =20 > + > + struct rte_cryptodev_data *data; > + /**< Pointer to device data */ > + struct rte_cryptodev_ops *dev_ops; > + /**< Functions exported by PMD */ > + uint64_t feature_flags; > + /**< Feature flags exposes HW/SW features for the given device */ > + struct rte_device *device; > + /**< Backing device */ > + > + uint8_t driver_id; > + /**< Crypto driver identifier*/ > + > + struct rte_cryptodev_cb_list link_intr_cbs; > + /**< User application callback for interrupts if present */ > + > + void *security_ctx; > + /**< Context for security ops */ > + > + __extension__ > + uint8_t attached : 1; > + /**< Flag indicating the device is attached */ > + > + struct rte_cryptodev_cb_rcu *enq_cbs; > + /**< User application callback for pre enqueue processing */ > + > + struct rte_cryptodev_cb_rcu *deq_cbs; > + /**< User application callback for post dequeue processing */ } > +__rte_cache_aligned; > + > +/** > + * The pool of rte_cryptodev structures. > + */ > +extern struct rte_cryptodev *rte_cryptodevs; > + > +#endif /* _RTE_CRYPTODEV_CORE_H_ */ > -- > 2.25.1