All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Cc: anatoly.burakov@intel.com,
	Stephen Hemminger <stephen@networkplumber.org>
Subject: [PATCH] doc/eal: add caveat about spinlocks from non-pinned threads
Date: Fri, 10 Jun 2022 08:28:19 -0700	[thread overview]
Message-ID: <20220610152819.38737-1-stephen@networkplumber.org> (raw)

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 <stephen@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)
+  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
+  the lock holder is once more rescheduled and releases the lock.
+
+
 cgroup control
 ~~~~~~~~~~~~~~
 
-- 
2.35.1


             reply	other threads:[~2022-06-10 15:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 15:28 Stephen Hemminger [this message]
2022-06-10 23:45 ` [PATCH] doc/eal: add caveat about spinlocks from non-pinned threads Tyler Retzlaff
2022-06-10 23:48 ` Tyler Retzlaff
2022-06-11  0:00   ` Stephen Hemminger
2022-06-11  1:55 ` fengchengwen
2022-06-11  3:33   ` Stephen Hemminger
2022-06-11 16:41 ` Mattias Rönnblom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220610152819.38737-1-stephen@networkplumber.org \
    --to=stephen@networkplumber.org \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.