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 6AA45A0508; Mon, 9 May 2022 05:48:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 042044069D; Mon, 9 May 2022 05:48:31 +0200 (CEST) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id 2ECA54068F for ; Mon, 9 May 2022 05:48:30 +0200 (CEST) Received: by mail-pl1-f177.google.com with SMTP id s14so12695442plk.8 for ; Sun, 08 May 2022 20:48:30 -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=UgO9u8SgSHOGRUAwYGBXsjqRrWMmrfdAN+KINCjwhtc=; b=M6OM7aQF+n2YrXwqHkPhMRJD46qaX1eqoL5aJsZtxBrDO1b6lXmA16djOtzQmuodB3 dCmVcnPP2iqOYnRCM7yd9e9kH6UXgQxjqKFeHA9OuhDkRzpQ7VWjE4lRqkR/IsiUElaZ /QU2RALk+jpik4qcWsPlkBQ4ip3qKEF3c9oUBcCoxP2ci/rF1WJSYNit4ISd1+5nmWPy HL6XNUDRT7vEqQiqFP4eo0xDDVK1kYx9eNqbfwIgejjR8XcLmkwGUEOXB2HpXAFv6hCq cQs4brUWIzBfGW5wnAOdOzKdpLD6+QGzunXP9e3n2UzGio7eHsbSMbl5gpk6E03MorWs gEmw== 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=UgO9u8SgSHOGRUAwYGBXsjqRrWMmrfdAN+KINCjwhtc=; b=FIe203NZUegJzeMYXWE6ST9s1gIv+XwqRASvM+MRtrzIe8Y26E6j/tjbuTQdybM1HM adnDLj9ISZEU5ByTmu2hfaqjFiKDDrmKoAjyv6+kUbVPJYg3k8sOX3oGlaaZdH0WMk7/ HhLezoDJPbE7oIhzq/ANKtrPKAPOnSc6lJALnl602ywEITqgoZPCWKoUSKdSozpePhy1 SyvxpJGV+4TtpFd/PM9se0OHqKEz85ypHwDMVmjE1FGlSgm7sNNx71ectsLZxXsPjZRT azwXPKTcUxe86gbRtJxEdpXeqvzObKnVDNOmrQk3k9MPPrCATjoBqmEziWxouAFnmTCc qLfg== X-Gm-Message-State: AOAM532rKYDiLKfseTW2qRIURfPZgmCRXW2QyQ2Rw9USUr68MKziPxR9 oQhjYskSB4470g+CNwhBkfdZkw== X-Google-Smtp-Source: ABdhPJxYtflQJ7dNJ/KtsqPFJG9csdcqFpesek3G5yd6RdT0E8R9HHLdd6q88kADDiqiT4Ad1MTKJg== X-Received: by 2002:a17:90b:4a4f:b0:1dc:79d9:8505 with SMTP id lb15-20020a17090b4a4f00b001dc79d98505mr24621428pjb.43.1652068109268; Sun, 08 May 2022 20:48:29 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id i13-20020a63584d000000b003c14af50606sm7151581pgm.30.2022.05.08.20.48.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 20:48:28 -0700 (PDT) Date: Sun, 8 May 2022 20:48:25 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Thomas Monjalon , David Marchand , dev@dpdk.org, onar.olsen@ericsson.com, Honnappa.Nagarahalli@arm.com, nd@arm.com, konstantin.ananyev@intel.com, mb@smartsharesystems.com, Chengwen Feng , Ola Liljedahl Subject: Re: [PATCH v6] eal: add seqlock Message-ID: <20220508204825.375965c8@hermes.local> In-Reply-To: <55ed0b2b-ebe6-fd48-48b8-d173a69d541f@lysator.liu.se> References: <20220508121242.290008-1-mattias.ronnblom@ericsson.com> <20220508091034.53b23b3e@hermes.local> <55ed0b2b-ebe6-fd48-48b8-d173a69d541f@lysator.liu.se> 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 Sun, 8 May 2022 21:40:58 +0200 Mattias R=C3=B6nnblom wrote: > > I think would be good to have the sequence count (read side only) like > > the kernel and sequence lock (sequence count + spinlock) as separate th= ings. > >=20 > > That way the application could use sequence count + ticket lock if it > > needed to scale to more writers. > > =20 >=20 > Sounds reasonable. Would that be something like: >=20 > typedef struct { > uint32_t sn; > } rte_seqlock_t; >=20 > rte_seqlock_read_begin() > rte_seqlock_read_retry() > rte_seqlock_write_begin() > rte_seqlock_write_end() >=20 > typedef struct { > rte_seqlock_t seqlock; > rte_spinlock_t wlock; > } rte__t; >=20 > rte__read_begin() > rte__read_retry() > rte__write_lock() > rte__write_unlock() >=20 > or are you suggesting removing the spinlock altogether, and leave=20 > writer-side synchronization to the application (at least in this DPDK=20 > release)? No, like Linux kernel. Use seqcount for the reader counter only object and seqlock for the seqcount + spinlock version.