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 84D3343C21; Thu, 7 Mar 2024 21:27:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 065DA402BA; Thu, 7 Mar 2024 21:27:35 +0100 (CET) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by mails.dpdk.org (Postfix) with ESMTP id 312D340272 for ; Thu, 7 Mar 2024 21:27:33 +0100 (CET) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-5cfd95130c6so972973a12.1 for ; Thu, 07 Mar 2024 12:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1709843252; x=1710448052; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=ddU62eDJuC/QNKnX3uIScangvsAK1Z4pfzV3GYtD1oM=; b=RG3IAm+gPl1W0o1qlEqTO07JFqN4H37hvbYGQgzBZsbRemr+e2ZyjOAB+Zn81uBtzv rlpuLsTTiAztFZvZYGVY2JbJ1OGD8o5S42fQm9VPKKVf79BuN0w+XK8QtnRtlNiuq1vp aFVTE8KQOY8x8vdatM7McLtDZFKmfz8wE3a0F0SmPp64FBNrA4UNmQc7xDJ5khEL7/t4 Mj5cmU+Wn6tKJkdpaS7mpwHxZzgfwt/MpSjQWXzhHLQMg5E3bvyN7uTVwpg2Qfbq2ugZ LB9qPJWDbcpgfvaos/Z7ToGuOg9IedXv3YHelgEDEo272RE3Jp2oJfzDMw15Dz4lKLk6 IQaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709843252; x=1710448052; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ddU62eDJuC/QNKnX3uIScangvsAK1Z4pfzV3GYtD1oM=; b=O4y9iZV5H9HRhgztEDFEEG9vtiwNCXd2KPIHBFsfYP7KwMC5PwyNmn91ryRVAKykn+ 22ov0CcC30grBh+wjkxPooNSsQ3mHrv36g0i1nxy6KMmXBm0aUQVSnoGH72fj9A3bCYQ 96mbZnwa/qZvaC5n/wc2BO+zfurYqiC6DHCnZ2mJ9QrE0ipeBJ1S5ZPRfEPFgwddz2fT Y+fcV0CqBQHLQ85mYBShSUPWnSRydzRR69TA1/tKxSFSaH5917TsnQXWu3d2VmDU9ACs +sG6kJDnbwnFJN8Ds/bUSNUyeh8IagfZUTCTrmJqzk/SOXCiD7NHBrviQ/ogSchGaDIH 3yyA== X-Forwarded-Encrypted: i=1; AJvYcCXNQZxk039gswInPvL1yegZRKo3lJIOQfjaMpibx2hNV/YNFEOECQT/7cf4MKCVV9XIgeUr1ZTKM58e9zg= X-Gm-Message-State: AOJu0YwcrnVaJ7GgUztz/HB/cI1c7Y6u9ky69NY0GcPZxRx3JzSyLPLW 9zGV1kUGGEEJ/HWfO4jMs5qSIW3l/ucCF4s2ihBR+76LY3KzIBc1RT93tqSeKEo= X-Google-Smtp-Source: AGHT+IGJl4AvvaCpNVSbEG2SqGBv6927zlXhbOS4xRGUnd7fo7ue5Yi0G+gwjQXJgdEVsNteR1Gl6A== X-Received: by 2002:a05:6a21:6da9:b0:1a1:487d:1c27 with SMTP id wl41-20020a056a216da900b001a1487d1c27mr9478342pzb.47.1709843252113; Thu, 07 Mar 2024 12:27:32 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id t20-20020a056a0021d400b006e64b9d88d4sm3526171pfj.124.2024.03.07.12.27.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 12:27:31 -0800 (PST) Date: Thu, 7 Mar 2024 12:27:30 -0800 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Tyler Retzlaff , "dev@dpdk.org" , Mattias =?UTF-8?B?UsO2bm5ibG9t?= Subject: Re: RTE lock Message-ID: <20240307122730.35a07d8b@hermes.local> In-Reply-To: References: <0024db51-8b39-4aa7-969a-bde86fe1c764@lysator.liu.se> <20240305210225.GA16095@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Thu, 7 Mar 2024 20:50:26 +0100 Mattias R=C3=B6nnblom wrote: > On 2024-03-05 22:02, Tyler Retzlaff wrote: > > On Tue, Mar 05, 2024 at 09:18:20PM +0100, Mattias R=C3=B6nnblom wrote: = =20 > >> Shouldn't we have a DPDK-native mutex API, rather than using direct > >> POSIX mutex lock calls? =20 > >=20 > > David raised this a while back and the consensus is yes. I admit it's > > been on my radar for a long time for the obvious reasons you list below > > but with other work hasn't been a priority (yet). > > =20 > >> > >> There are two reasons for this, as I see it > >> 1) more cleanly support non-POSIX operating system (i.e., Microsoft > >> Windows). > >> 2) to discourage mechanical use of spinlocks in places where a > >> regular mutex lock is more appropriate. > >> > >> I think (and hope) DPDK developers will tend to pick DPDK-native > >> rather than other APIs as their first choice. =20 > >=20 > > I spent some time evaluating C11 mutex but it really didn't strike me as > > being fit for purpose so I think DPDK-native is probably the only way to > > go. If behind the scenes particular locks relied on something standard > > for Windows perhaps it could be hidden as an implementation detail. > > =20 >=20 > What was it you were missing? >=20 > I'm not familiar with C11 mtx_*() >=20 > >> > >> For locks, they go for spinlocks, even in control (non-fast > >> path/non-packet processing) code paths (e.g., calls made by the > >> typical non-EAL thread). > >> > >> Using spinlocks to synchronize threads that may be preempted aren't > >> great idea. =20 > >=20 > > If you're thinking of looking into this i'd be happy to see it solved. > > =20 >=20 > I have no immediate plans, but this might be something I'll do in the=20 > future. >=20 > > ty =20 For Linux, what would be good is a simplified version of what pthread_mutex does. The current code for pthread_mutex in glibc has a lot of indirection and complexity which definately slows down the fast uncontended path. Ideally, an inline version using futex. Glibc has so much indirection because it supports so many mutex variants and operating systems like mach and hurd...