From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0A94FA0553; Sat, 11 Jun 2022 05:33:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9FEAD40222; Sat, 11 Jun 2022 05:33:18 +0200 (CEST) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by mails.dpdk.org (Postfix) with ESMTP id 81E9840041 for ; Sat, 11 Jun 2022 05:33:17 +0200 (CEST) Received: by mail-pf1-f179.google.com with SMTP id y196so1053401pfb.6 for ; Fri, 10 Jun 2022 20:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CwIXyYkNORKaap9vMKE1aStF7kG6Usu6ECVtxGnlvvU=; b=71SXlXfwv8bn0BeOKa7SMIg1+DBBg/MZWOZv1Z435fuk72cfJDB0k1r4GTL9KBNbQ6 JoxXFWzb+mIvdiFjEbfVKiwQoCeTpv9FmcIu0gJR054Ss2W1nLJ+nDoWVbC0YhRCZuGQ wmDQFRx3fOZA+ouJeB6IWu8fuscQAzd9uyU6vNjQfO0urZb/jLKtVNCIbdnFLBcrP/y9 eGWJPLXDlbXbw7aklwhgmiYP7w7FWLuNDmA+5T8lFT+HincgrABncd04fVWPVvq+dHK0 Ss67amAvrJWE2VjP4OYy2pwl1RD/dXW1peK2hHr0sZAEtJTiO/AklYeyi//SHI5neno6 sfYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CwIXyYkNORKaap9vMKE1aStF7kG6Usu6ECVtxGnlvvU=; b=ivuaMGiZJpD74D2fGcgZZoXAvMiExCeBIH3nBIBfiFS12owdy7ZN2T/uik/9xXaNos hmlc1J/9aCuzIAqxbh68tFm8XXTEjga9HLpmWmln29a4VTo3uL4CyUxDYfXL5wpZ44Pz pILmlPcoPVWvTJOUMYSKFc8pX6yCC/MOxL0MUhJu1BA/Seq0hPdu1b8tx+T/ssKAHtL3 O5aIs7AUKhBKYwP6+nmd7cvxSxpFN2JquohKx3xGPPuWhWBX/DiFuXed+LNYWxiveXMJ WuNMbZJrM0H7ns4i00hH3ZQ56ufUnl4KnHFu7KraNZS4z9Icl08OaV/8S8R6WgPzm28E jrLw== X-Gm-Message-State: AOAM5332guxq6hARQwks35sxbL7mYKYNSvFhe03sxMEA1GdTmWdBLRle dE41JrlaH+254nBGQ+pSZ4+3KA== X-Google-Smtp-Source: ABdhPJwB7TDuP7Mc4u1ZGF4xypZoVu3wH6/e0UcnpZDF9v9IUkjulmF1++VCj7D5kvo2yAk8pbSwSQ== X-Received: by 2002:a63:4844:0:b0:3fc:c299:a7a4 with SMTP id x4-20020a634844000000b003fcc299a7a4mr42049845pgk.510.1654918396516; Fri, 10 Jun 2022 20:33:16 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id n12-20020a63720c000000b003fbb455040dsm441882pgc.84.2022.06.10.20.33.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 20:33:16 -0700 (PDT) Date: Fri, 10 Jun 2022 20:33:12 -0700 From: Stephen Hemminger To: fengchengwen Cc: , Subject: Re: [PATCH] doc/eal: add caveat about spinlocks from non-pinned threads Message-ID: <20220610203312.6a25f0c6@hermes.local> In-Reply-To: References: <20220610152819.38737-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Sat, 11 Jun 2022 09:55:00 +0800 fengchengwen 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 > > --- > > 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.