From patchwork Fri Jun 10 15:28:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Hemminger X-Patchwork-Id: 112658 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EEB75A0553; Fri, 10 Jun 2022 17:28:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 895354069C; Fri, 10 Jun 2022 17:28:25 +0200 (CEST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id CDEBD40689 for ; Fri, 10 Jun 2022 17:28:24 +0200 (CEST) Received: by mail-pf1-f178.google.com with SMTP id z17so24128739pff.7 for ; Fri, 10 Jun 2022 08:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=1k3y+gO++2c9lGSmhxBlDp0SJFfM+EmAsQ0kUg1dCcg=; b=sTYKmcDckb1gxnl7fXi4igx+nS3IR9qqU0gTTn99uU8S+1Gzaat0lpehaK/zowDjeA BusZhrVG0uPeAkOA+zP/kO+l3JN23Ti0Mw6UKSS7byVJ2pZuIYM8E3Jvgk8h9e8zbENx ZS4oqEoFoywnaudwMDEVAzGVEVQMXwWSKLjZJqhP1zHtOTiLss3zWficOdv9f3CONep7 QROWRYOzESFNo7++nej3LsbhNyl0cC3fTsLxCo+VmxB1zsOZv0t3NK7r7+4eud6lJnMN qyTZjxefRZQf0usSI3mbeD4Zn4HkIcfkXMT5fl2bv6xIezqkn5/dqOKy3qvJopiADkCm j1WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=1k3y+gO++2c9lGSmhxBlDp0SJFfM+EmAsQ0kUg1dCcg=; b=vw1UcmBwbExJQpNzWjHj+eiy7Nw3TEBc/8mCnJ1DcJBV5dZ0i1DXy0ntVvCDyW5cVw Ox8aH0kbD6eYqmLAZZUaA1h/EOHISCxS9Ad6rtt+XPqBofACq0UtC61dKs4RSb+5r6cB mwPskugjhzkD/vW+NjnXShkh0sdmFQgPeZm1Ni99ZKed0z+QKUziMjoglFtRJ4lXp3V+ c2H8OQlD8XJGPGUCt+NwJm8WXDImm2h6jAqHGkOr7ZK3iS1MzuYorwHylFg1gOqMOxa7 PLBBfWu1HSh9kzV9GfRM3VnHUdohTV20xOEwBIDqX3As3bwJHlPI2AYISqq9ITa6/HYi YnHg== X-Gm-Message-State: AOAM531ShiNfX6+8LiYhByLWjF33uQdkKlPYwTujrf515yvgtXaFXb98 JJq6zSRYrsdj8HND8cEWzxhZ+aHi5ALPEKLH X-Google-Smtp-Source: ABdhPJxcbKGoxasapmv1mloySF7IsBv2X/atyOGnwEs5VyWioCUt+vWbbphrVIDsZGsnrU+yonNfWA== X-Received: by 2002:a63:135b:0:b0:3fd:876c:975a with SMTP id 27-20020a63135b000000b003fd876c975amr27341677pgt.538.1654874903225; Fri, 10 Jun 2022 08:28:23 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id b8-20020a631b48000000b003fadd680908sm19495917pgm.83.2022.06.10.08.28.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 08:28:22 -0700 (PDT) From: Stephen Hemminger To: dev@dpdk.org Cc: anatoly.burakov@intel.com, Stephen Hemminger Subject: [PATCH] doc/eal: add caveat about spinlocks from non-pinned threads Date: Fri, 10 Jun 2022 08:28:19 -0700 Message-Id: <20220610152819.38737-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 Acked-by: Tyler Retzlaff --- 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 ~~~~~~~~~~~~~~