<snip>
> > > rte_eal_remote_launch and rte_eal_wait_lcore need to provide correct > > memory ordering to address the data communication from main core to > > worker core and vice versa. > > > > There are 2 use cases: > > 1) All the store operations (meant for worker) by main core should be > > visible to worker core before the worker core runs the assigned > > function > > > > 2) All the store operations by the worker core should be visible to > > the main core after rte_eal_wait_lcore returns. > > > > For the data that needs to be communicated to the worker after the > > rte_eal_remote_launch returns, load-acquire and store-release > > semantics should be used (just like any other writer-reader use case). > > > > For the main to worker communication, the pointer to function to > > execute is used as the guard variable. Hence, resetting of the > > function pointer is important. > > > > For the worker to main communication, the existing code uses the lcore > > state as the guard variable. However, it looks like the FINISHED state > > is not really required. Hence the FINISHED state is removed before > > using the state as the guard variable. I would like some feedback on > > why the FINISHED state is required. I have not paid attention to what > > it means for backward compatibility. > > If it is decided to remove this state, documentation changes are > > required. > > > > > Most likely all use of volatile in DPDK is suspect. > Perhaps we should re-enable the "volatile considered harmful" warning in > checkpatch Agree.
