From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 53F173230 for ; Thu, 3 May 2018 08:10:04 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 23:10:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,356,1520924400"; d="scan'208";a="52001772" Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91]) by fmsmga001.fm.intel.com with ESMTP; 02 May 2018 23:10:01 -0700 Received: from pgsmsx102.gar.corp.intel.com ([169.254.6.245]) by PGSMSX104.gar.corp.intel.com ([169.254.3.13]) with mapi id 14.03.0319.002; Thu, 3 May 2018 14:10:00 +0800 From: "Gujjar, Abhinandan S" To: Akhil Goyal , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "dev@dpdk.org" CC: "Vangati, Narender" , "Rao, Nikhil" , "Eads, Gage" Thread-Topic: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter Thread-Index: AQHT28nS3+7/tBq/xEKnOqyz+ojb3KQQ5/kAgAGZDFD//55UgIALcgOg Date: Thu, 3 May 2018 06:10:00 +0000 Message-ID: <5612CB344B05EE4F95FC5B729939F78070701D64@PGSMSX102.gar.corp.intel.com> References: <1524573807-168522-1-git-send-email-abhinandan.gujjar@intel.com> <1524573807-168522-2-git-send-email-abhinandan.gujjar@intel.com> <58e0ed01-ac5c-1da3-0f0e-b3a90cfb7b0c@nxp.com> <5612CB344B05EE4F95FC5B729939F780706FF9E6@PGSMSX102.gar.corp.intel.com> <6febc20d-7bcd-88f8-aba7-b06dc737ea4f@nxp.com> In-Reply-To: <6febc20d-7bcd-88f8-aba7-b06dc737ea4f@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGFlMjcxYmQtMjM4Zi00NmIwLWI4MzEtN2QyNzczNjg4YWI2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjdHOGJYYU1UUkZ0VVRtbEkxcFc0QURMeEs2QUF5R1NuemRBWDVGZHoyQjg9In0= dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter 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: , X-List-Received-Date: Thu, 03 May 2018 06:10:05 -0000 Hi Akhil, > -----Original Message----- > From: Akhil Goyal > Sent: Thursday, April 26, 2018 12:47 PM > To: Gujjar, Abhinandan S ; Akhil Goyal > ; jerin.jacob@caviumnetworks.com; > hemant.agrawal@nxp.com; dev@dpdk.org > Cc: Vangati, Narender ; Rao, Nikhil > ; Eads, Gage > Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter >=20 > Hi Abhinandan, > On 4/26/2018 11:37 AM, Gujjar, Abhinandan S wrote: > > Hi Akhil, > > > >> -----Original Message----- > >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > >> Sent: Wednesday, April 25, 2018 6:12 PM > >> To: Gujjar, Abhinandan S ; > >> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com; > >> akhil.goyal@nxp.com; dev@dpdk.org > >> Cc: Vangati, Narender ; Rao, Nikhil > >> ; Eads, Gage > >> Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto > >> adapter > >> > >> Hi Abhinandan, > >> On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote: > >>> Signed-off-by: Abhinandan Gujjar > >>> Signed-off-by: Nikhil Rao > >>> Signed-off-by: Gage Eads > >>> --- > >>> lib/librte_eventdev/rte_event_crypto_adapter.h | 532 > >>> +++++++++++++++++++++++++ > >>> 1 file changed, 532 insertions(+) > >>> create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h > >>> > >>> diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h > >>> b/lib/librte_eventdev/rte_event_crypto_adapter.h > >>> new file mode 100644 > >>> index 0000000..aa4f32c > >>> --- /dev/null > >>> +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h > >>> @@ -0,0 +1,532 @@ > >>> +/* SPDX-License-Identifier: BSD-3-Clause > >>> + * Copyright(c) 2017-2018 Intel Corporation */ > >>> + > >>> +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_ > >>> +#define _RTE_EVENT_CRYPTO_ADAPTER_ > >>> + > >>> +/** > >>> + * @file > >>> + * > >>> + * RTE Event crypto adapter > >>> + * > >>> + * Eventdev library provides couple of adapters to bridge between > >>> +various > >>> + * components for providing new event source. The event crypto > >>> +adapter is > >>> + * one of those adapter which is intended to bridge between event > >>> +devices > >>> + * and crypto devices. > >>> + * > >>> + * The crypto adapter adds support to enqueue/dequeue crypto > >>> +operations to/ > >>> + * from event device. The packet flow between crypto device and the > >>> +event > >>> + * device can be accomplished using both SW and HW based transfer > >> mechanisms. > >>> + * The adapter uses an EAL service core function for SW based > >>> +packet transfer > >>> + * and uses the eventdev PMD functions to configure HW based packet > >>> +transfer > >>> + * between the crypto device and the event device. > >>> + * > >>> + * The application can choose to submit a crypto operation directly > >>> +to > >>> + * crypto device or send it to the crypto adapter via eventdev, the > >>> +crypto > >>> + * adapter then submits the crypto operation to the crypto device. > >>> + * The first mode is known as the dequeue only (DEQ_ONLY) mode and > >>> +the > >>> + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of > >>> +mode can > >>> + * be specified while creating the adapter. > >>> + * > >>> + * > >>> + * Working model of DEQ_ONLY mode: > >>> + * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> + * > >>> + * +--------------+ +--------------+ > >>> + * Events | | | Crypto stage | > >>> + * <------>| Event device |-------->| + enqueue to | > >>> + * | | | cryptodev | > >>> + * +--------------+ +--------------+ > >>> + * event ^ | > >>> + * enqueue| | crypto > >>> + * | v enqueue > >>> + * +--------------+ +--------------+ > >>> + * | | | | > >>> + * |Crypto adapter|<--------| Cryptodev | > >>> + * | | | | > >>> + * +--------------+ +--------------+ > >>> + * > >> The diagram looks a bit cryptic. Enqueue to cryptodev will be done > >> from application and not from event device. The arrow from event > >> device to crypto stage is not clear. And application dequeues events > >> from event device. So that should not be bidirectional arrow. > > > > You are right, it is done from application. But the application will > > be in the crypto stage of pipeline. Since crypto is an intermediate > > stage, events are first dequeued from eventdev to find out it's a crypt= o stage. > Then application, in the crypto stage, enqueue "rte_crypto_ops" > > to cryptodev and finally adapter enqueue crypto completions as events t= o > eventdev. > > From this point, eventdev will pass events to the next stage (may be Tx= ). > > That's the reason behind bidirectional arrow to event device. > > > You are talking about a particular application, but the comments should b= e > generic. In DEQ ONLY mode, enqueue to cryptodev is responsibility of > application and should not be from event dev. Actually the application wi= ll > dequeue from event dev and decide that this event comes from NIC (say), a= nd it > needs to be processed by cryptodev next. So in this case the application = decides > what will happen to the packet and not the event dev, so it cannot be bi- > directional arrow. I will update the diagram with sequence numbers providing more information on what's happening at each block. This will give more clarity. BTW, the arrow from eventdev to crypto is unidirectional. >=20 > >> > >>> + * In the DEQ_ONLY mode, application submits crypto operations > >>> + directly to > >>> + * crypto device. The adapter then dequeues crypto completions from > >>> + crypto > >>> + * device and enqueue events to the event device. > >>> + * In this mode, application needs to specify event information > >>> + (response > >>> + * information) which is needed to enqueue an event after the > >>> + crypto operation > >>> + * is completed. > >>> + * > >>> + * > >>> + * Working model of ENQ_DEQ mode: > >>> + * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> + * > >>> + * +--------------+ +--------------+ > >>> + * Events | | | | > >>> + * <------>| Event device |-------->| Crypto stage | > >>> + * | | | | > >>> + * +--------------+ +--------------+ > >>> + * event ^ | > >>> + * enqueue| | event > >>> + * | v dequeue > >>> + * +---------------------------------------+ > >>> + * | | > >>> + * | Crypto adapter | > >>> + * | | > >>> + * +---------------------------------------+ > >>> + * ^ > >>> + * | crypto > >>> + * | enq/deq > >>> + * v > >>> + * +-------------+ > >>> + * | | > >>> + * | Cryptodev | > >>> + * | | > >>> + * +-------------+ > >>> + * > >>> + * In the ENQ_DEQ mode, application sends crypto operations as > >>> + events to > >>> + * the adapter which dequeues events and perform cryptodev operation= s. > >>> + * The adapter dequeues crypto completions from cryptodev and > >>> + enqueue > >>> + * events to the event device. > >>> + * In this mode, the application needs to specify the cryptodev ID > >>> + * and queue pair ID (request information) needed to enqueue a > >>> + crypto > >>> + * operation in addition to the event information (response > >>> + information) > >>> + * needed to enqueue an event after the crypto operation has complet= ed. > >>> + * > >>> + * > >>> + * The event crypto adapter provides common APIs to configure the > >>> + packet flow > >>> + * from the crypto device to event devices for both SW and HW based > >> transfers. > >>> + * The crypto event adapter's functions are: > >>> + * - rte_event_crypto_adapter_create_ext() > >>> + * - rte_event_crypto_adapter_create() > >>> + * - rte_event_crypto_adapter_free() > >>> + * - rte_event_crypto_adapter_queue_pair_add() > >>> + * - rte_event_crypto_adapter_queue_pair_del() > >>> + * - rte_event_crypto_adapter_start() > >>> + * - rte_event_crypto_adapter_stop() > >>> + * - rte_event_crypto_adapter_stats_get() > >>> + * - rte_event_crypto_adapter_stats_reset() > >>> + > >>> + * The applicaton creates an instance using > >>> + rte_event_crypto_adapter_create() > >> application spell check. > >> > >>> + * or rte_event_crypto_adapter_create_ext(). > >>> + * > >>> + * Cryptodev queue pair addition/deletion is done using the > >>> + * rte_event_crypto_adapter_queue_pair_xxx() APIs. > >>> + * > >>> + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide > >>> + whether > >>> + * request/response(private) data is located in the crypto/security > >>> + session > >>> + * or at an offset in the rte_crypto_op. > >>> + * The rte_crypto_op::private_data_offset provides an offset to > >>> + locate the > >>> + * request/response information in the rte_crypto_op. > >> Above line is repeated below. This one can be removed. > > Ok. I will combine them. > >> > >>> + * > >>> + * For session-based operations, the set and get API provides a > >>> + mechanism for > >>> + * an application to store and retrieve the data information stored > >>> + * along with the crypto session. > >>> + > >>> + * For session-less mode, the adapter gets the private data > >>> + information placed > >>> + * along with the ``struct rte_crypto_op``. > >>> + * The ``rte_crypto_op::private_data_offset`` indicates the start > >>> + of private > >>> + * data information. The offset is counted from the start of the > >>> + rte_crypto_op > >>> + * including initialization vector (IV). > >>> + */ > >>> + > >>> +#ifdef __cplusplus > >>> +extern "C" { > >>> +#endif > >>> + > >>> +#include > >>> + > >>> +#include "rte_eventdev.h" > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this enum may change without prior notice > >>> + * > >>> + * Crypto event adapter mode > >>> + */ > >>> +enum rte_event_crypto_adapter_mode { > >>> + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY =3D 1, > >>> + /**< Start only dequeue part of crypto adapter. > >>> + * Application submits crypto requests to the cryptodev. > >>> + * Adapter only dequeues the crypto completions from cryptodev > >>> + * and enqueue events to the eventdev. > >>> + */ > >>> + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ, > >>> + /**< Start both enqueue & dequeue part of crypto adapter. > >>> + * Application submits crypto requests as events to the crypto > >>> + * adapter. Adapter submits crypto requests to the cryptodev > >>> + * and crypto completions are enqueued back to the eventdev. > >>> + */ > >>> +}; > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this structure may change without prior notice > >>> + * > >>> + * Crypto event request structure will be filled by application to > >>> + * provide event request information to the adapter. > >>> + */ > >>> +struct rte_event_crypto_request { > >>> + uint8_t resv[8]; > >>> + /**< Overlaps with first 8 bytes of struct rte_event > >>> + * that encode the response event information > >>> + */ > >> I think in case of ENQ_DEQ mode, both request and response info is > >> required. I think it would be better to have a single structure as > >> > >> struct rte_event_crypto_metadata { > >> struct rte_event ev; > >> uint16_t cdev_id; > >> uint16_t queue_pair_id; > >> uint32_t resv1; > >> }; > >> The last 3 fields need not be filled by application for DEQ_ONLY mode. > >> Application will not get confused with request/response structures > >> when we have response info already present in request structure. > >> Or if you still insist to have separate structure for request and > >> response then it would be better to have it as struct instead of > >> union for metadata and remove the resv[8]. > >> IMO, first one is better. > > > > rte_event structure itself has enough memory to hold *both request and > response information*. > > struct rte_event { > > /** WORD0 */ > > union { > > uint64_t event; > > . > > } > > /** WORD1 */ > > union { > > uint64_t u64; > > . > > } > > } > > > > For response only *WORD0* is used. Whereas *WORD1* is used for request! > > > > As proposed, > > +struct rte_event_crypto_request { > > + uint8_t resv[8]; > > + /**< Overlaps with first 8 bytes of struct rte_event > > + * that encode the response event information > > + */ > > + uint16_t cdev_id; > > + /**< cryptodev ID to be used */ > > + uint16_t queue_pair_id; > > + /**< cryptodev queue pair ID to be used */ > > + uint32_t resv1; > > + /**< Reserved bits */ > > +}; > > > > First 8 bytes are *WORD0* and rest of the information fits into *WORD1*= . > > +union rte_event_crypto_metadata { > > + struct rte_event_crypto_request request_info; > > + struct rte_event response_info; > > +}; > > Request and response together into a union will allocate memory require= d for > (WORD0+WORD1). > > I hope, this clarifies all your doubt. > > > Ok I missed the WORD1 in my previous comment. But my intention was to hav= e > a common structure of metadata. As in case of ENQ-DEQ mode, both request > and response will be filled. So having a structure with a union of reques= t and > response will be misleading. >=20 > >> > >>> + uint16_t cdev_id; > >>> + /**< cryptodev ID to be used */ > >>> + uint16_t queue_pair_id; > >>> + /**< cryptodev queue pair ID to be used */ > >>> + uint32_t resv1; > >>> + /**< Reserved bits */ > >>> +}; > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this structure may change without prior notice > >>> + * > >>> + * Crypto event metadata structure will be filled by application > >>> + * to provide crypto request and event response information. > >>> + * > >>> + * If crypto events are enqueued using a HW mechanism, the cryptodev > >>> + * PMD will use the event response information to set up the event > >>> + * that is enqueued back to eventdev after completion of the crypto > >>> + * operation. If the transfer is done by SW, event response > >>> +information > >>> + * will be used by the adapter. > >>> + */ > >>> +union rte_event_crypto_metadata { > >>> + struct rte_event_crypto_request request_info; > >>> + struct rte_event response_info; > >>> +}; > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this structure may change without prior notice > >>> + * > >>> + * Adapter configuration structure that the adapter configuration > >>> +callback > >>> + * function is expected to fill out > >>> + * @see rte_event_crypto_adapter_conf_cb */ struct > >>> +rte_event_crypto_adapter_conf { > >>> + uint8_t event_port_id; > >>> + /**< Event port identifier, the adapter enqueues events to this > >>> + * port and also dequeues crypto request events in ENQ_DEQ mode. > >>> + */ > >>> + uint32_t max_nb; > >>> + /**< The adapter can return early if it has processed at least > >>> + * max_nb crypto ops. This isn't treated as a requirement; batching > >>> + * may cause the adapter to process more than max_nb crypto ops. > >>> + */ > >>> +}; > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this API may change without prior notice > >>> + * > >>> + * Function type used for adapter configuration callback. The > >>> +callback is > >>> + * used to fill in members of the struct > >>> +rte_event_crypto_adapter_conf, this > >>> + * callback is invoked when creating a SW service for packet transfe= r > >>> +from > >>> + * cryptodev queue pair to the event device. The SW service is > >>> +created within > >>> + * the rte_event_crypto_adapter_queue_pair_add() function if SW base= d > >>> +packet > >>> + * transfers from cryptodev queue pair to the event device are requi= red. > >>> + * > >>> + * @param id > >>> + * Adapter identifier. > >>> + * > >>> + * @param dev_id > >>> + * Event device identifier. > >>> + * > >>> + * @param conf > >>> + * Structure that needs to be populated by this callback. > >>> + * > >>> + * @param arg > >>> + * Argument to the callback. This is the same as the conf_arg passe= d > >>> +to the > >>> + * rte_event_crypto_adapter_create_ext(). > >>> + */ > >>> +typedef int (*rte_event_crypto_adapter_conf_cb) (uint8_t id, uint8_t > dev_id, > >>> + struct rte_event_crypto_adapter_conf *conf, > >>> + void *arg); > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this structure may change without prior notice > >>> + * > >>> + * Queue pair configuration structure containing event information. > >>> + * @see > >> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND > >>> + */ > >>> +struct rte_event_crypto_queue_pair_conf { > >>> + struct rte_event ev; > >>> +}; > >> We may not need this wrapper structure. We can directly use rte_event. > > This was done keep in mind to accommodate need for any future requireme= nt > > of having a new field added to the structure along with the rte_event. > > > Do you see anything in the future for configuration. If not, we can > remove it for now and should add in future when it is required. Sure. I will remove it in next patch. >=20 > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this structure may change without prior notice > >>> + * > >>> + * A structure used to retrieve statistics for an event crypto > >>> +adapter > >>> + * instance. > >>> + */ > >>> + > >>> +struct rte_event_crypto_adapter_stats { > >>> + uint64_t event_poll_count; > >>> + /**< Event port poll count */ > >>> + uint64_t event_dequeue_count; > >> better to use uniform naming. event_deq_count > > ok > >>> + /**< Event dequeue count */ > >>> + uint64_t crypto_enq_count; > >>> + /**< Cryptodev enqueue count */ > >>> + uint64_t crypto_enq_fail; > >>> + /**< Cryptodev enqueue failed count */ > >>> + uint64_t crypto_deq_count; > >>> + /**< Cryptodev dequeue count */ > >>> + uint64_t event_enqueue_count; > >> event_enq_count > > ok > >>> + /**< Event enqueue count */ > >>> + uint64_t event_enq_retry_count; > >>> + /**< Event enqueue retry count */ > >>> + uint64_t event_enq_fail_count; > >>> + /**< Event enqueue fail count */ > >>> +}; > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this API may change without prior notice > >>> + * > >>> + * Create a new event crypto adapter with the specified identifier. > >>> + * > >>> + * @param id > >>> + * Adapter identifier. > >>> + * > >>> + * @param dev_id > >>> + * Event device identifier. > >>> + * > >>> + * @param conf_cb > >>> + * Callback function that fills in members of a > >>> + * struct rte_event_crypto_adapter_conf struct passed into > >>> + * it. > >>> + * > >>> + * @param mode > >>> + * Flag to indicate to start dequeue only or both enqueue & dequeue= . > >>> + * > >>> + * @param conf_arg > >>> + * Argument that is passed to the conf_cb function. > >>> + * > >>> + * @return > >>> + * - 0: Success > >>> + * - <0: Error code on failure > >>> + */ > >>> +int __rte_experimental > >>> +rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id, > >>> + rte_event_crypto_adapter_conf_cb conf_cb, > >>> + enum rte_event_crypto_adapter_mode mode, > >>> + void *conf_arg); > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this API may change without prior notice > >>> + * > >>> + * Create a new event crypto adapter with the specified identifier. > >>> + * This function uses an internal configuration function that create= s > >>> +an event > >>> + * port. This default function reconfigures the event device with an > >>> + * additional event port and setups up the event port using the > >>> +port_config > >> set up > >>> + * parameter passed into this function. In case the application need= s > >>> +more > >>> + * control in configuration of the service, it should use the > >>> + * rte_event_crypto_adapter_create_ext() version. > >>> + * > >>> + * @param id > >>> + * Adapter identifier. > >>> + * > >>> + * @param dev_id > >>> + * Event device identifier. > >>> + * > >>> + * @param port_config > >>> + * Argument of type *rte_event_port_conf* that is passed to the > >>> +conf_cb > >>> + * function. > >>> + * > >>> + * @param mode > >>> + * Flag to indicate to start dequeue only or both enqueue & dequeue= . > >>> + * > >>> + * @return > >>> + * - 0: Success > >>> + * - <0: Error code on failure > >>> + */ > >>> +int __rte_experimental > >>> +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id, > >>> + struct rte_event_port_conf *port_config, > >>> + enum rte_event_crypto_adapter_mode mode); > >>> + > >> [..snip..] > >> > >>> + > >>> +/** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this API may change without prior notice > >>> + * > >>> + * Retrieve the event port of an adapter. > >>> + * > >>> + * @param id > >>> + * Adapter identifier. > >>> + * > >>> + * @param [out] event_port_id > >>> + * Event port identifier used to link to the queue used in ENQ_DEQ = mode. > >>> + * > >>> + * @return > >>> + * - 0: Success > >>> + * - <0: Error code on failure. > >>> + */ > >>> +int __rte_experimental > >>> +rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t > >>> +*event_port_id); > >> IIUC, crypto adapter can give packets to multiple event ports. > > There could be multiple event ports from cryptodev to eventdev in the H= W > > which you are referring, by looking at DEQ mode. This API is used only = for > > ENQ-DEQ mode. The SW adapter is using only one event port to do the job= . > A comment shall be added in the description if that is the case. I have added a comment just below " param [out] event_port_id". I will try = to add some more information, if possible. > >> > >> Also, I don't see similar API in eth_rx_adapter. > > As eth_rx_adapter does not dequeue any events from application, > > this API is not present there. >=20 > Regards, > Akhil