On Mon, 12 Oct 2026 at 20:53, Marat Khalili <[email protected]> wrote: > > On 09/10/2026 07:05, Wathsala Vithanage wrote: > >> /* > >> * Marks given callback as used by datapath. > >> */ > >> static __rte_always_inline void > >> bpf_eth_cbi_inuse(struct bpf_eth_cbi *cbi) > >> { > >> - cbi->use++; > >> - /* make sure no store/load reordering could happen */ > >> - rte_smp_mb(); > >> + rte_atomic_store_explicit(&cbi->use, > >> + rte_atomic_load_explicit(&cbi->use, > >> rte_memory_order_relaxed) + 1, > >> + rte_memory_order_relaxed); > >> + > >> + /* full barrier: count must be visible before cb is read */ > >> + rte_atomic_thread_fence(rte_memory_order_seq_cst); > > NAK: optimizing this increment makes little sense when more careful > analysis shows that it can be simply removed. > > I highly recommend keeping this patchset dedicated to removing > rte_smp_XX barriers and moving other bpf_pkt.c improvements elsewhere.
This blocks the SMP barrier removal for rc1. What is your proposal? I think it makes sense to take https://patchwork.dpdk.org/project/dpdk/list/?series=39599 first, then resolve the conflict for the patch from this thread. Is this BPF series ready for merge? If it is not ready yet, what should be done on the current patch? Is a s/rte_smp_rmb()/rte_atomic_thread_fence(rte_memory_order_seq_cst)/ enough? The commitlog would also need some rewritting. -- David Marchand
