> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Sunday, July 17, 2022 4:17 PM
> To: Akhil Goyal <gak...@marvell.com>; Srujana Challa
> <scha...@marvell.com>
> Cc: roy.fan.zh...@intel.com; dev@dpdk.org; Jerin Jacob Kollanukkaran
> <jer...@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpu...@marvell.com>; Anoob Joseph <ano...@marvell.com>;
> david.march...@redhat.com; bruce.richard...@intel.com;
> konstantin.v.anan...@yandex.ru; ma...@nvidia.com;
> honnappa.nagaraha...@arm.com
> Subject: [EXT] Re: [RFC PATCH] cryptodev: add return parameter to callback
> process API
>
> External Email
>
> ----------------------------------------------------------------------
> 24/06/2022 14:12, Srujana Challa:
> > Adds a return parameter "uint16_t qp_id" to the functions
> > rte_cryptodev_pmd_callback_process and rte_cryptodev_cb_fn.
> > The new parameter is used to return queue pair ID to the application
> > when it gets error interrupt, so that application can disable and
> > enable the queue pair, to bring the queue back to normal state.
>
> What about other events?
>
> > + * @param qp_id Return parameter from driver to the application.
> Driver
> > + * returns queue pair ID when it gets HW error
> interrupt.
> > + * The application can release and setup the queue
> > + * again, to bring the HW queue back to normal state.
>
> What will it mean if the event is not related to queues?
>
> > * @param event Crypto device event to register for notification of.
> > * @param cb_arg User specified parameter to be passed as to passed
> to
> > * users callback function.
>
> Are you going to add a new callback parameter each time the application
> needs info about a new event?
>
> In my opinion, it is a very bad idea.
> As done in ethdev, you should add a query function specific to the event.
>
> Example: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__git.dpdk.org_dpdk_commit_-3Fid-
> 3Dbc70e5594838&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Fj4OoD5hcK
> FpANhTWdwQzjT1Jpf7veC5263T47JVpnc&m=SUn-
> UVCQXX4KwyuDDcIb_PvE4MwkLTimQ3ox7hHcKW7wCq6BzW2849tn1nq2dO
> S1&s=aSpFxjeE4xjxZadI9wxc5AqInIvinSvFfa0NEeRrxBA&e=
> Here, when a threshold is reached, an event
> RTE_ETH_EVENT_RX_AVAIL_THRESH is fired, and the application can get
> more info about what happened by calling the function
> rte_eth_rx_avail_thresh_query().
> Look at the parameters description:
> "
> @param[inout] queue_id
> On input starting Rx queue index to search from.
> If the queue_id is bigger than maximum queue ID of the port, search is
> started from 0. So that application can keep calling this function to handle
> all
> pending events with a simple increment of queue_id on the next call.
> On output if return value is 1, Rx queue index with the event pending.
> @param[out] avail_thresh
> Location for available descriptors threshold of the found Rx queue.
> "
>
Agree with your comment. Will work on to implement query API for events. But as
of now we only have single error event.
