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 6050043F6C; Thu, 2 May 2024 23:46:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25D2A402C9; Thu, 2 May 2024 23:46:38 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id 30F04402C4 for ; Thu, 2 May 2024 23:46:37 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-6eddff25e4eso7349773b3a.3 for ; Thu, 02 May 2024 14:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1714686396; x=1715291196; 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=Lncn1bv2nrY7ma7btUaLYfoOuVkQ8KUbYmYeLZo8B14=; b=znVRsY1wQrLTMseMBMbFx91AWrmuFKkPrsfFZIyXKYE1L7xn8zIqeV/gkggijyp4Mn 8Rz4HxKeEWeUYif96eq8Vdu+AGeOdlaamAoi9MarKb9mBZ7AcCvFv7kQrnA1Bjcz9c5O 7/r99L4LI7bWj1VZuP/aypim/NNvGS9xTpwRE0SA5sPu3vVuMq/jYEK7CKSMuPsvSlOJ EaZbMXtgFFaev8rD55w/i0XnLVNgXOuCz2Bdee5MxIf+O3DLRplNXPhTIvkqD0M3yQWo 9uVnj8gnmrOXIxaqV9fR8aAZ8H+UtPEhWKVr81fAwzUHtV0HU+X1U+NP8vom8KsE09V1 OwsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714686396; x=1715291196; 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=Lncn1bv2nrY7ma7btUaLYfoOuVkQ8KUbYmYeLZo8B14=; b=HFFrXzi86DKf2l+cKYuxlKjca6Bo31Vwyq7exvYDW3NlN4KBjflHbQBiR/g22VzOuY dOt277vusJj7v7rI+F1pNSvENRvy9Tv+91f4fPV958K1kw1/2Q68ckgs28iQf3Vf4M1Q 3+yUj9PTR7b2th/5MH3hoBRW6TcT0k4lukX3eJ7tBKd0Lqg7wUD0D/Lxp1vr5MHqQaS4 sRLrdQtcKIqeToHgNohGrFrdxQ8WM0VXSmTdm+bKl4+RUmt3S/U6VRCtjRZD6r3+eX4K indVZEmKsYNpnghaKcrhw18OuetinSrnFPA4Go4h7oYQUc9Z/Yfi2/wB9JG0MJeC9Iad s5OQ== X-Forwarded-Encrypted: i=1; AJvYcCVb2ZNJ6o39A1Y2+0td/iYb5SBa/iuX7v2OpU18gpTnsiKBZshDLlLBdyQ4XUYlgXrlvRc0YkhBb0cB8yY= X-Gm-Message-State: AOJu0YxaO8R/wZTNOC2GApc7Gjt5Ihr5hxoSKFpUGAao4V8AvKZl4Ewr Y9O//p1kdfMyJiKKYpDTNTZR07T5vi6589PldAsgK/XZ/0EGqPZbkEQYH6dcLQc= X-Google-Smtp-Source: AGHT+IFodZI3JFrssD+EQeDW5AnVfp70gsGQEbHet1PimEHRM9XakLTP1CgBMt2Ua5TSL78ZytTBcw== X-Received: by 2002:a05:6a20:d80c:b0:1af:7bbc:9f86 with SMTP id iv12-20020a056a20d80c00b001af7bbc9f86mr1035402pzb.0.1714686396276; Thu, 02 May 2024 14:46:36 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id fn14-20020a056a002fce00b006ed045af796sm1750071pfb.88.2024.05.02.14.46.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 May 2024 14:46:36 -0700 (PDT) Date: Thu, 2 May 2024 14:46:34 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Ferruh Yigit , "John W. Linville" , Thomas Monjalon , dev@dpdk.org, Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Morten =?UTF-8?B?QnLDuHJ1cA==?= Subject: Re: [RFC v2] net/af_packet: make stats reset reliable Message-ID: <20240502144634.1808da56@hermes.local> In-Reply-To: References: <20240425174617.2126159-1-ferruh.yigit@amd.com> <20240426143848.2280689-1-ferruh.yigit@amd.com> <108e0c40-33e7-4eed-83de-eaedee454480@lysator.liu.se> <7e5dd3cd-ea50-4aea-a350-d88f46854172@amd.com> <422dd5a6-4ed6-4ae5-b613-b22a7cf6f77d@amd.com> <758132fe-fc44-4c06-8e54-c0439f3a693f@lysator.liu.se> <20240502112602.27d55fb8@hermes.local> 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, 2 May 2024 23:26:31 +0200 Mattias R=C3=B6nnblom wrote: > >=20 > > You are confusing atomic usage for thread safety, with the necessity > > of compiler barriers. > > =20 >=20 > Are you suggesting that program-level C11 atomic stores risk being=20 > delayed, indefinitely? I could only find a draft version of the=20 > standard, but there 7.17.3 says "Implementations should make atomic=20 > stores visible to atomic loads within a reasonable amount of time." >=20 > An atomic relaxed store will be much cheaper than a compiler barrier. There is a confusion between language designers C11 and system implementer = and CPU design. The language people confuse compiler with hardware in standards. Because of course the compiler knows all (not). Read the extended discussion on memory models in Linux kernel documentation. https://www.kernel.org/doc/html/latest/core-api/wrappers/memory-barriers.ht= ml