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 6C56743FDA; Wed, 8 May 2024 22:54:25 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EDA704026E; Wed, 8 May 2024 22:54:24 +0200 (CEST) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by mails.dpdk.org (Postfix) with ESMTP id 0F98F40042 for ; Wed, 8 May 2024 22:54:22 +0200 (CEST) Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-6f489e64eb3so211588b3a.1 for ; Wed, 08 May 2024 13:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1715201662; x=1715806462; 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=dX5rcC6Xt1hrrdFOgcgbzb9zByh+Itch7Nw2+P0Edb4=; b=i1RTlz4vuvlq2PQKBxk4Wxfkz+vTRbMD2EP8ftKoOPXDvjIyoC8n9cWhJsDxOLz/l6 FkVb27Ad8lAmVK22yl9PJKksgq0kfqs8yTSrU4ggaCFT1XVBIruZpKUQ+7X4x+JAtTw/ nQcyUUt8nxp0wE7JM/TUXE5ZJVJX6RNIm2Io5J8mUqDbg/uupTzZdPUc3rtVlcZuGniQ r5M2vpRlW7FCii3WsT3ACZ3TL+hVKcA2BmD156k97G1BZzKPJI3MXC7oQdGazCbRYKt6 Ou+lp60jLtnqlmgzscLbHZPXsAcXItUwOPYcMIoZM2MzuH4tlRdlQyBYB1YasO+IJpef +5Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715201662; x=1715806462; 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=dX5rcC6Xt1hrrdFOgcgbzb9zByh+Itch7Nw2+P0Edb4=; b=u0vMALUjwetLrEGUEmHImRy6LCfVJ4mfzOScJXolawzaAavld/UtZREn5O/IDfZ5Sa wASSRVfF6s+4A+dwb88vM5SLt1jR4ekoP/pSlUZaSskUBFMHguQ08kJW7GmEP2UqINso OT+zxT9qwSogICYM1a4tQeYwqLI3CmqEqVxhK0CDrkdyqoRE8bn0/RwaLRpAUXmGGjGY WhR70Ngg+iVSH589ifBk2Eq194uc4jCyQQOymuV2BFjr4UkuJsxrP4DALGjEDKnu+I5N uClrsFCFCmTnJCr+01sm8whAgs0zFq5IOH8FzBbIR2U61Et4hfIN6ZSIWz9g8V4pq3X9 L89w== X-Forwarded-Encrypted: i=1; AJvYcCWd0PQlcCaJhBrFI6lFZmLQFMjQ6xE6jvlwG/MmV+jtvFwIPHDXB0ew0z1rPje5ja/en0h7ZZQN2JKws6s= X-Gm-Message-State: AOJu0YzCFP6qypsKqcbxMI8VnFHmuthXScsCHlEqYYU8w9hV+Ulj07hS Gm2oA3dIACNCt8OnIBcKw3ntr94honYPVAok2cqvdjVGtbwCbGJXdtzJZI2KM4o= X-Google-Smtp-Source: AGHT+IHRI9T208yDPoDH1GSrpVwW2wROOVznHPTpRY/SzhqRpa/60q5z5CciuM5ddXDyMkM5dExSAg== X-Received: by 2002:a05:6a21:7982:b0:1af:a47a:329e with SMTP id adf61e73a8af0-1afc8d690e4mr4841757637.37.1715201662016; Wed, 08 May 2024 13:54:22 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4d2a6654asm10967b3a.43.2024.05.08.13.54.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 May 2024 13:54:21 -0700 (PDT) Date: Wed, 8 May 2024 13:54:18 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , "John W. Linville" , Thomas Monjalon , dev@dpdk.org, Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Morten =?UTF-8?B?QnLDuHJ1cA==?= Subject: Re: [RFC v3] net/af_packet: make stats reset reliable Message-ID: <20240508135418.55505105@hermes.local> In-Reply-To: <834102e5-8f4b-4b67-9f62-8e8f61403b39@amd.com> References: <20240425174617.2126159-1-ferruh.yigit@amd.com> <20240503154547.392069-1-ferruh.yigit@amd.com> <20240503150011.55681b97@hermes.local> <432fb280-96e3-4079-b987-990d509b8c79@lysator.liu.se> <20240508082339.6bf74202@hermes.local> <834102e5-8f4b-4b67-9f62-8e8f61403b39@amd.com> 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 Wed, 8 May 2024 20:48:06 +0100 Ferruh Yigit wrote: > > > > The idea of load tearing is crazy talk of integral types. It would break so many things. > > It is the kind of stupid compiler thing that would send Linus on a rant and get > > the GCC compiler writers in trouble. > > > > The DPDK has always favored performance over strict safety guard rails everywhere. > > Switching to making every statistic an atomic operation is not in the spirit of > > what is required. There is no strict guarantee necessary here. > > > > I kind of agree with Stephen. > > Thanks Mattias, Morten & Stephen, it was informative discussion. But for > *SW drivers* stats update and reset is not core functionality and I > think we can be OK to get hit on corner cases, instead of > over-engineering or making code more complex. I forgot the case of 64 bit values on 32 bit platforms! Mostly because haven't cared about 32 bit for years... The Linux kernel uses some wrappers to handle this. On 64 bit platforms they become noop. On 32 bit platform, they are protected by a seqlock and updates are wrapped by the sequence count. If we go this way, then doing similar Noop on 64 bit and atomic or seqlock on 32 bit should be done, but in common helper. Looking inside FreeBSD, it looks like that has changed over the years as well. if_inc_counter counter_u64_add atomic_add_64 But the counters are always per-cpu in this case. So although it does use locked operation, will always be uncontended. PS: Does DPDK still actually support 32 bit on x86? Can it be dropped this cycle?