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 63BE544044; Fri, 17 May 2024 02:20:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DDC0E402C2; Fri, 17 May 2024 02:20:00 +0200 (CEST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by mails.dpdk.org (Postfix) with ESMTP id B369940285 for ; Fri, 17 May 2024 02:19:58 +0200 (CEST) Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-6f490b5c23bso732885b3a.3 for ; Thu, 16 May 2024 17:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1715905198; x=1716509998; 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=5oBDg51eduIQUqlti7dSlqvltmgrAQk4g+KsX44nRO4=; b=oQALhRQZT61fJcXync+kNzIlC8B+RtI5u9EPx5HSWpE3g6NEjTkqSziSf3bQLylIre P/9GFfkzYiS7f3owr6e9YNx/cCu+A29/ZFK09/Hd0GlWaSYUykeCUdq14fxrYyBLL9bN 17AB1PsTAuWMfiI119LJTM2liCbDirWKasyntymwMEosSq+HD4/H5kQxfLI9uNCiKsPQ y0c58OOPQW8NrqKxvOito5TajedIfYhvm/ZImdeI0VnJHN0LMnf9qeyJyWSr0twpmEOz M1MZi5ESBozqRN+Z5U4gwCN/X0sGY0Sj4JwOdURPVGLQLjz/WiUVYBl5rtQtqeFMC/wh cM8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715905198; x=1716509998; 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=5oBDg51eduIQUqlti7dSlqvltmgrAQk4g+KsX44nRO4=; b=mj4DRWBcZuvnAlbNQGzjKfdedrG4NzoIcfGS9uM2lZ/cSdenv0E/D0XQd1dYlf25Jc /W77HrD1/7NDZETYC79sHFY1GwV3m+PbMn3MVaNLuBPbThkXFA+aZcnQl8l1kZhyXIJy 8DS4JFepKa4e8TnaOIU45PYrLBBU/gaJCi8Uqtk8hEGOCG96SC8XHbdMNH156flOWpJx Kxm7s4ORIfU8IAW8w0KtZkkG1pdUwrNS8yVghXqKeOdVxLBJxR0rtcGM1YEsN8xmrWXW 014CJJrZhtC3jw8MqcaQEq7uLOxjfGi85f0RiXZeQpJMY+DXuUCLbZ0BxnJwskiEfAxp b4DQ== X-Gm-Message-State: AOJu0Yz9lRms9nXE4QxujFq4j07Ex82on9NP0Dw+VZ4duQdGtrG41sEk QCRdz/A4c3BINN/GdoRqJUAMNirLSrntrtZPetFD2ldlQ8AdCT6UyNFaiGsE3pk= X-Google-Smtp-Source: AGHT+IHdsDsGVUdiSXRcNsFlBTdKL3AUVmk8+mDTYhR9YEKGiezPJwu7yNdJACbL7AA8+KDqcWCKTQ== X-Received: by 2002:a05:6a00:b51:b0:6ed:88e5:53d4 with SMTP id d2e1a72fcca58-6f4e02aa365mr25034576b3a.8.1715905197558; Thu, 16 May 2024 17:19:57 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4d2ae0da1sm13683096b3a.107.2024.05.16.17.19.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 May 2024 17:19:57 -0700 (PDT) Date: Thu, 16 May 2024 17:19:55 -0700 From: Stephen Hemminger To: Wathsala Wathawana Vithanage Cc: "dev@dpdk.org" , "thomas@monjalon.net" , Ferruh Yigit , Andrew Rybchenko , nd Subject: Re: [PATCH v5 2/9] ethdev: add common counters for statistics Message-ID: <20240516171955.005c97e8@hermes.local> In-Reply-To: References: <20240510050507.14381-1-stephen@networkplumber.org> <20240516154327.64104-1-stephen@networkplumber.org> <20240516154327.64104-3-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 16 May 2024 18:30:52 +0000 Wathsala Wathawana Vithanage wrote: > > + packets = rte_counter64_fetch(&counters->packets); > > + bytes = rte_counter64_fetch(&counters->bytes); > > + errors = rte_counter64_fetch(&counters->errors); > > + > > + rte_compiler_barrier(); > > + > > + stats->ipackets += packets; > > + stats->ibytes += bytes; > > + stats->ierrors += errors; > > + > > there seems to be a dependency chain in the above loads and subsequent stores. > If that's the case what's the purpose of the compiler barrier? > > --wathsala It is so that the counters returned per queue are the same as the count across all queues. A really annoying compiler could in the process of inlining everything on 64 bit, decide that it didn't need to have these temporary variables. It could read counters->packets twice, once for the total and once for the per-queue values. In the intervening window, the PMD could have received another packet. This is a pre-existing purely theoretical bug across all these drivers. The Linux kernel has started using tools to find these.