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 7947AA00C2; Sun, 3 Apr 2022 08:23:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 59DF34068A; Sun, 3 Apr 2022 08:23:46 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id A40E340041 for ; Sun, 3 Apr 2022 08:23:45 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6998F1327F for ; Sun, 3 Apr 2022 08:23:44 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 680B61327E; Sun, 3 Apr 2022 08:23:44 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -3.5 Received: from [192.168.1.59] (unknown [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 711991367B; Sun, 3 Apr 2022 08:23:43 +0200 (CEST) Message-ID: Date: Sun, 3 Apr 2022 08:23:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2] eal: add seqlock Content-Language: en-US To: Stephen Hemminger , Ola Liljedahl Cc: "dev@dpdk.org" , Thomas Monjalon , David Marchand , Onar Olsen , "Honnappa.Nagarahalli@arm.com" , "nd@arm.com" , "konstantin.ananyev@intel.com" , "mb@smartsharesystems.com" References: <98CBD80474FA8B44BF855DF32C47DC35D86F84@smartserver.smartshare.dk> <20220330142602.108061-1-mattias.ronnblom@ericsson.com> <3888e595-de18-3cf0-707b-309b153c2b02@ericsson.com> <37d60d0f-9911-7692-cdb6-62cd5da540ac@arm.com> <1094901f-ee27-8c49-d71f-825ec5bfe2ad@arm.com> <20220401145217.66506c78@shemminger-XPS-13-9360> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: <20220401145217.66506c78@shemminger-XPS-13-9360> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2022-04-02 02:52, Stephen Hemminger wrote: > On Thu, 31 Mar 2022 16:53:00 +0200 > Ola Liljedahl wrote: > >> From: Ola Liljedahl >> To: Mattias Rönnblom , "dev@dpdk.org" >> Cc: Thomas Monjalon , David >> Marchand , Onar Olsen >> , "Honnappa.Nagarahalli@arm.com" >> , "nd@arm.com" , >> "konstantin.ananyev@intel.com" , >> "mb@smartsharesystems.com" , >> "stephen@networkplumber.org" Subject: >> Re: [PATCH v2] eal: add seqlock Date: Thu, 31 Mar 2022 16:53:00 +0200 >> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 >> Thunderbird/91.7.0 >> >> (Thunderbird suddenly refuses to edit in plain text mode, hope the >> mail gets sent as text anyway) >> >> On 3/31/22 15:38, Mattias Rönnblom wrote: >> >>> On 2022-03-31 11:04, Ola Liljedahl wrote: >>>> On 3/31/22 09:46, Mattias Rönnblom wrote: >>>>> On 2022-03-30 16:26, Mattias Rönnblom wrote: >>>>> >> >>>>> Should the rte_seqlock_read_retry() be called >>>>> rte_seqlock_read_end(), or some third alternative? I wanted to >>>>> make clear it's not just a "release the lock" function. You could >>>>> use the|||__attribute__((warn_unused_result)) annotation to make >>>>> clear the return value cannot be ignored, although I'm not sure >>>>> DPDK ever use that attribute. >>>> We have to decide how to use the seqlock API from the application >>>> perspective. >>>> Your current proposal: >>>> do { >>>>     sn = rte_seqlock_read_begin(&seqlock) >>>>     //read protected data >>>> } while (rte_seqlock_read_retry(&seqlock, sn)); >>>> >>>> or perhaps >>>> sn = rte_seqlock_read_lock(&seqlock); >>>> do { >>>>     //read protected data >>>> } while (!rte_seqlock_read_tryunlock(&seqlock, &sn)); >>>> >>>> Tryunlock should signal to the user that the unlock operation >>>> might not succeed and something needs to be repeated. >>>> >>> I like that your proposal is consistent with rwlock API, although I >>> tend to think about a seqlock more like an arbitrary-size atomic >>> load/store, where begin() is the beginning of the read transaction. >>> >> >> I can see the evolution of an application where is starts to use >> plain spin locks, moves to reader/writer locks for better performance >> and eventually moves to seqlocks. The usage is the same, only the >> characteristics (including performance) differ. > > > The semantics of seqlock in DPDK must be the same as what Linux kernel > does or you are asking for trouble. It is not a reader-writer lock in > traditional sense. Does "semantics" here including the naming of the functions? The overall semantics will be the same, except the kernel has a bunch of variants with different kind of write-side synchronization, if I recall correctly. I'll try to summarize the options as I see them: Option A: (PATCH v3): rte_seqlock_read_lock() rte_seqlock_read_tryunlock() /* with built-in "read restart" */ rte_seqlock_write_lock() rte_seqlock_write_unlock() Option B: (Linux kernel-style naming): rte_seqlock_read_begin() rte_seqlock_read_end() rte_seqlock_write_begin() rte_seqlock_write_end() A combination, acknowledging there's a lock on the writer side, but not on the read side. Option C: rte_seqlock_read_begin() rte_seqlock_read_retry() rte_seqlock_write_lock() rte_seqlock_write_unlock()