On Sat, 11 Jun 2022 09:55:00 +0800 fengchengwen <fengcheng...@huawei.com> wrote:
> On 2022/6/10 23:28, Stephen Hemminger wrote: > > Need to warn users of DPDK spinlocks from non-pinned threads. > > This is similar wording to Linux documentation in pthread_spin_init. > > > > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > > --- > > doc/guides/prog_guide/env_abstraction_layer.rst | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst > > b/doc/guides/prog_guide/env_abstraction_layer.rst > > index 5f0748fba1c0..45d3de8d84f6 100644 > > --- a/doc/guides/prog_guide/env_abstraction_layer.rst > > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst > > @@ -797,6 +797,16 @@ Known Issues > > > > The debug statistics of rte_ring, rte_mempool and rte_timer are not > > supported in an unregistered non-EAL pthread. > > > > ++ locking > > + > > + If a pthread, that is not pinned to an lcore acquires a lock such as a > > + DPDK based lock (rte_spinlock, rte_rwlock, rte_ticketlock, rte_mcslock) > > Some APIs inherently use rte_spinlock, just like rte_malloc/rte_eal_alarm_set, > Because DPDK API mainly use rte_spinlock to support thread-safty. > > Suggest declare DPDK API mainly use rte_spinlock to support thread-safty, so > if the caller thread is not pinned to an lcore may encount a possibility of > large application delays. I copied text from pthread_spinlock man page. The same caveats apply to pthread_spinlocks as DPDK; therefore using same wording seemed appropriate. But it is worth mentioning that other API's may depend on spinlocks internally.
