Re: [RFC 15/32] event/sw: fix unlinks in progress counter races

Bruce Richardson <[email protected]>
Newsgroups org.dpdk.dev
Message-ID <[email protected]>
On Wed, Jul 29, 2026 at 10:54:08AM -0700, Stephen Hemminger wrote:
> The counter is written by both the application thread (increment on
> unlink) and the scheduler (clear on ack) as a plain uint8_t. An
> increment is lost if it lands between the scheduler's test and clear,
> making rte_event_port_unlinks_in_progress() report completion before
> the scheduler has seen the unlink. Nothing orders the scheduler's
> later cq map reads against the counter test on a weakly ordered CPU
> either.
> 
> Make the counter atomic: release fetch-add on unlink, acquire
> exchange to clear. The exchange cannot lose a concurrent increment,
> and the acquire guarantees the scheduler only acks unlinks whose cq
> map update it can observe, replacing the full barrier in unlink.
> 
> Fixes: bd5ac24fea88 ("event/sw: implement unlinks in progress function")
> Cc: [email protected]
> 
> Signed-off-by: Stephen Hemminger <[email protected]>
Acked-by: Bruce Richardson <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.