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 3A88544051; Fri, 17 May 2024 17:07:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C007C402E9; Fri, 17 May 2024 17:07:20 +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 E823440268 for ; Fri, 17 May 2024 17:07:18 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1f0937479f8so11414075ad.3 for ; Fri, 17 May 2024 08:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1715958438; x=1716563238; 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=kBH0TsqPiLE9jyNUmfw3sk6A/99eppypVrTuajkVxGs=; b=0aTSRPsArKSF0SDxL+DiY8pshuBZhnT1NemgOK6LDcwIDuo13fxMLeHe5wNOBUlkqA qaXdEC4vbiKWbCDgYprkXELcl8AicYPWculEHPDDoDvdNWunVF2EyYsfTJrR3ZcRmMqD dzOtIM7rmRu+hwOD0N6afTKE3s4sm0HAuX80DKW1Or5BVRTkoul2Anyv3njUxTZOC4wP AtvvBQRd7VkWNrKjcw06kPYXuXVhxuggYjBxSGR0plCcu+LPKNEFNOD2Pi8DzbM1HwRo 45ImU0jtS8Wz+gseEzslG1omzPs1MJlpFLEgRJqVqpNFtdZFBUPPazH1fWKRIkwNWsUj NOiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715958438; x=1716563238; 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=kBH0TsqPiLE9jyNUmfw3sk6A/99eppypVrTuajkVxGs=; b=u5BepWPEzBVoRiclIiCBXJGUeiUlBozcp8OntnPTtO8nNUb6ZUVymfdOF+31vgLrKx SHAHMkmDYOCsJmJr5+3UzhTgj3Xd23IGlMQTum4dhVEeCYsbnP5XCFhROh5d+BTnogZ+ rnIkOxXcs+FcIoFTle6scUGw6efBfzV3aLa/Ja/pW6GAXjIMcZcEHTtiWZypf2XM/1G1 Ozb1biesQ7OfloTQhPJ+r07znfSzSlpB+TL+Mwg0sEfaiNJHsSfqkIuiSacQzwJKVoai ip9+HFiFBoMLmmYp39eOtgk2mDQ1Z9yzyOrXnnFG6Bcg5OZ/Onda/PHqVdBsmSgPRQ18 PKCg== X-Gm-Message-State: AOJu0Yx8gHlvX98KGHuDagWLvfVr90Npe+s007URRBCqBI4sBSHrabNy HeTx4Bs0QNdqxgcsz9YuJ3y8f8aunZeTS5YprQCu31BxQR2wcSpNn5VqEBM4TFY= X-Google-Smtp-Source: AGHT+IFGt8yNEpBMQUcVjtDUQDe7UoT5rcGhftg485x9BJkAK3+2mjEer5yozdAV+nsVzk7CUrE8SA== X-Received: by 2002:a17:90a:4418:b0:2ac:5a93:636b with SMTP id 98e67ed59e1d1-2b6cc34280dmr19029591a91.2.1715958437800; Fri, 17 May 2024 08:07:17 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2b6c51b3482sm14173946a91.20.2024.05.17.08.07.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 May 2024 08:07:17 -0700 (PDT) Date: Fri, 17 May 2024 08:07:15 -0700 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: "dev@dpdk.org" , Morten =?UTF-8?B?QnLDuHJ1cA==?= , nd , "Richardson, Bruce" Subject: Re: [PATCH v6 1/9] eal: generic 64 bit counter Message-ID: <20240517080715.413e93e4@hermes.local> In-Reply-To: <248621D2-C402-4DDE-92D8-F5377E816533@arm.com> References: <20240510050507.14381-1-stephen@networkplumber.org> <20240517001302.65514-1-stephen@networkplumber.org> <20240517001302.65514-2-stephen@networkplumber.org> <48ED00A3-1CCA-4F64-ACC3-CA1F0D2B9378@arm.com> <20240516203037.73ec13e1@hermes.local> <248621D2-C402-4DDE-92D8-F5377E816533@arm.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 Fri, 17 May 2024 04:26:58 +0000 Honnappa Nagarahalli wrote: > > > > The C standard has always guaranteed that read and write to unsigned log will not be split. > As I understand, this is true only if the variable is an atomic variable. If not, there is no difference between atomic variables and non-atomic variables. Let me look. It certainly falls under the "if a compiler did this it is crazy and would never be able to run Linux" per Linus. > > > Therefore if arch is 64 bit native there is no need for atomics > At least on ARM architecture, if the variable is not aligned on 8B boundary, the load or store are not atomic. I am sure it is the same on other architectures. > Bruce, any comments for x86? This code needs to assume alignment to 8B. I'll document that. But no runtime checks please.