On 2/1/2024 8:43 AM, David Marchand wrote:
> As described in a recent bugzilla opened against the net/iavf driver,
> a driver may call a event callback from other calls of the ethdev API.
>
> Nothing guarantees in the ethdev API against such behavior.
>
> Add a notice against using locks in those callbacks.
>
> Bugzilla ID: 1337
>
> Signed-off-by: David Marchand <david.march...@redhat.com>
> ---
> lib/ethdev/rte_ethdev.h | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 21e3a21903..5c6b104fb4 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -4090,7 +4090,19 @@ enum rte_eth_event_type {
> RTE_ETH_EVENT_MAX /**< max value of this enum */
> };
>
> -/** User application callback to be registered for interrupts. */
> +/**
> + * User application callback to be registered for interrupts.
> + *
> + * Note: there is no guarantee in the DPDK drivers that a callback won't be
> + * called in the middle of other parts of the ethdev API. For example,
> + * imagine that thread A calls rte_eth_dev_start() and as part of this
> + * call, a RTE_ETH_EVENT_INTR_RESET event gets generated and the
> + * associated callback is ran on thread A. In that example, if the
> + * application protects its internal data using locks before calling
> + * rte_eth_dev_start(), and the callback takes a same lock, a deadlock
> + * occurs. Because of this, it is highly recommended NOT to take locks
> in
> + * those callbacks.
> + */
> typedef int (*rte_eth_dev_cb_fn)(uint16_t port_id,
> enum rte_eth_event_type event, void *cb_arg, void *ret_param);
>
Acked-by: Ferruh Yigit <ferruh.yi...@amd.com>
