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://git.dpdk.org/dpdk/commit/?id=bc70e5594838 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. "
