2016-06-15 05:30, Pattan, Reshma: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-06-14 10:38, Reshma Pattan: > > > Added spinlocks around add/remove logic of Rx and Tx callbacks to > > > avoid corruption of callback lists in multithreaded context. > > > > > > Signed-off-by: Reshma Pattan <reshma.pattan at intel.com> > > > > Why cb->next is not locked in burst functions? > It is safe to do "read access" here and doesn't require any locking as rx/tx > burst is initiated by only local user(control plane) thread. > > > Just protecting add/remove but not its usage seems useless. > Here locks were required around add/remove to protect "write access" > because write to callback list is now done from 2 threads > i.e. one from local user thread(control plane) and another from pdump control > thread(initiated by remote pdump request).
So read and write can be done by different threads. I think the read access would need locking but we do not want it in fast path. Are you sure there is no issue in this design?
