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 90708A0548; Wed, 1 Jun 2022 18:15:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3611640689; Wed, 1 Jun 2022 18:15:49 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 8351A4003F for ; Wed, 1 Jun 2022 18:15:47 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id u18so2250547plb.3 for ; Wed, 01 Jun 2022 09:15:47 -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=mYeRSUKfO6NKqLtRyE+5aXY97vZjC8eo9ueMbrFBxpA=; b=ND5kvU5ykVTO5xBiRWLI7kPI4hiL2VO8hh6FC/MfWbyg5LhjNCFdtSHVzgmRal4fV0 yqhZRlC4LNTlmeaoU0t1S4tjm+wAKaxHjuT/uY4nAr/6zmwqP3nEvHow6bnN8OZAoAAI vuEuNxvZQLiIhPiVdTlxyP20KpRGQidYLIUEgW0uthrXCZdSIHsza+Gyk4cKJCgp1hkJ 8kDGlq/KZ6n1hoLPHysU2mYwlwRTN14XGzlp9jilJVhncKoRkZJZL5wGhQxQSD9Mi42N akNF76cPbW1PzvhxSnyhxbgvpsqZVPekhbtYS4U3pDgg0iTazSVcgail46mYZjp1byyz SGXw== 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=mYeRSUKfO6NKqLtRyE+5aXY97vZjC8eo9ueMbrFBxpA=; b=Q1GPA10uvdLjTlbJDv8wglJJsu1OBax82x+YaBH0cDhv99ynqi+ycCzVpnvGR3zORN m582WYFSvZABTVlAh562QjqqI7tBw8RCaFddiaqbUYs7ue9IFfS+ePize3RBluj+445l CY8LqAcL3aG4CgzNItUQnqHd0QNXBRbCQSjdZZyKhRqLQySARPFiiXJhDa1j/9c6Cdt3 Ny19n2h3RYnD98fs6jXnIgPqKg7Iuji25QC2XLfe3qQ9ogty5m1kzDmI5pse5DmS9xHs nO2g02ONPYjjRdaszd8UtWcysOd+hFZgtMxNhzn5akRgAZC2dh91ZvKymUyBeRNP5ccF 3kxw== X-Gm-Message-State: AOAM5323OyF2+qrdyAmNYeFlXv3wH1mSwrviOiOy/JCge/chy1uhKcFu yLz4I7qa2ykQD3g/2bDliR//aA== X-Google-Smtp-Source: ABdhPJxxy21Vr+ANzsV1Al1UXOa2ic8gTQ0RUULLG2mXhrQ0vLfACdjngFkK7V/jniXHXn1LQUXf6w== X-Received: by 2002:a17:902:6b08:b0:165:fd6:6abd with SMTP id o8-20020a1709026b0800b001650fd66abdmr214467plk.152.1654100146527; Wed, 01 Jun 2022 09:15:46 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id e17-20020a17090301d100b0015e8d4eb237sm1741188plh.129.2022.06.01.09.15.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 09:15:46 -0700 (PDT) Date: Wed, 1 Jun 2022 09:15:43 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Thomas Monjalon , David Marchand , "dev@dpdk.org" , Onar Olsen , "Honnappa.Nagarahalli@arm.com" , "nd@arm.com" , "konstantin.ananyev@intel.com" , "mb@smartsharesystems.com" , "hofors@lysator.liu.se" , Chengwen Feng , Ola Liljedahl Subject: Re: [PATCH v9] eal: add seqlock Message-ID: <20220601091543.08e3e83b@hermes.local> In-Reply-To: <60dd49ad-c323-4286-749e-79e174accabc@ericsson.com> References: <20220523113111.366599-1-mattias.ronnblom@ericsson.com> <20220523142346.366902-1-mattias.ronnblom@ericsson.com> <20220531154536.52f57bf6@hermes.local> <60dd49ad-c323-4286-749e-79e174accabc@ericsson.com> 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 Wed, 1 Jun 2022 08:19:54 +0000 Mattias R=C3=B6nnblom wrote: > On 2022-06-01 00:45, Stephen Hemminger wrote: > > On Mon, 23 May 2022 16:23:46 +0200 > > Mattias R=C3=B6nnblom wrote: > > =20 > >> +/** > >> + * The RTE seqcount type. > >> + */ > >> +typedef struct { > >> + uint32_t sn; /**< A sequence number for the protected data. */ > >> +} rte_seqcount_t; =20 > >=20 > > Don't need structure for only one element. > > =20 >=20 > The struct adds a degree of type safety, with no run-time cost. Makes sense. >=20 > > typedef uint32_t rte_seqcount_t; > >=20 > > + if (unlikely(begin_sn !=3D end_sn)) > > + return true; > > + > > + return false; > >=20 > > Prefer to avoid conditional if possible (compiler will optimize it as): > >=20 > > return begin_sn =3D=3D end_sn; =20 >=20 > Is this a readability argument, or a performance one? >=20 > The compiler might use the unlikely hint to do something useful, like=20 > avoiding a branch in the common case. It is a matter of taste. I always prefer writing the smallest (within reaso= n) amount of code as possible. And my preference is to do things with declarat= ive and data statements rather than conditionals.