Okay, so here the issue is still rte_eth_dev_stop(), but not rte_eth_dev_rx_queue_stop(), right? I mean, as long as not calling rte_eth_dev_stop() on control path, is it safe to call rte_eth_dev_rx_queue_stop/rte_eth_dev_rx_queue_start on control path while
fast path keeps calling rte_eth_rx_burst()?
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Monday, February 17, 2025 2:06 PM
To: Changchun Zhang <changchun.zhang@oracle.com>
Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; NAGENDRA BALAGANI <nagendra.balagani@oracle.com>; users@dpdk.org <users@dpdk.org>
Subject: Re: [External] : Re: Query Regarding Race Condition Between Packet Reception and Device Stop in DPDK
On Mon, 17 Feb 2025 18:57:00 +0000
Changchun Zhang <changchun.zhang@oracle.com> wrote:
> Hi Harry,
>
> Can we call rte_eth_dev_rx_queue_stop() on a rx queue when a fast path is still polling the queue? The sequence on control and fast path cores would like:
> Control path:
> rte_eth_dev_rx_queue_stop(rx_queue_id);
> ...waiting for draining of rx_queue...
> rte_eth_dev_stop()
> ....
>
> Fast path:
> Keep calling rte_eth_rx_burst()
> (I am expecting it will return 0 if queue is already drained and stopped)
>
No.
The application needs to not call rx_burst when stop is being done.
There rx_burst is a fast path with no additional checks and is intentionally not thread safe.
You need to coordinate queue management inside the application.