Thank you raising your concerns. I mean, the original wrong code, but using -O3 optimization yielded a correct result. My patch makes the effects of -O3 and -O0 consistent.
Unlike other signals that require busy wait, this callback pointer only needs to be read once. So I don't think memory barriers and volatile are needed here. >On Thu, 5 Mar 2020 01:33:49 +0800 >ZY Qiu <quze...@gmail.com> wrote: > >> When compiling with -O0, >> the compiler does not optimize two memory accesses into one. >> Leads to accessing a null pointer when queue post Rx burst callback >> removal while traffic is running. >> See rte_eth_tx_burst function. >> >> Signed-off-by: ZY Qiu <tgw_t...@tencent.com> > >This is a problem many places in DPDK. You said it was related to -O0 >but that is just what is causing a more generic problem to be exposed. >Your solution is not sufficient. > >DPDK is sloppy in several places in handling memory ordering issues > https://en.wikipedia.org/wiki/Memory_ordering > >It should have a macro to do RTE_READ_ONCE(). Several drives have this, >the Linux kernel has it, Liburcu has it. > >The macro RTE_READ_ONCE() can then be used in many places in DPDK.
