On Fri, Jun 10, 2022 at 08:28:19AM -0700, 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
nit: suggest not using term pthread but instead just say thread as not to imply a specific platform/implementation. > + DPDK based lock (rte_spinlock, rte_rwlock, rte_ticketlock, rte_mcslock) > + then there is a possibility of large application delays. > + The problem is that if a thread is scheduled off the CPU while it holds > + a lock, then other threads will waste time spinning on the lock until 'until the lock holder' -> 'until the thread holding the lock' but i'm not really fussed, just a suggestion. > + the lock holder is once more rescheduled and releases the lock. > + > + > cgroup control > ~~~~~~~~~~~~~~ > > -- > 2.35.1
