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 55065A04A2; Sun, 16 Jan 2022 17:32:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A22A40E50; Sun, 16 Jan 2022 17:32:25 +0100 (CET) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id 0D7C040683 for ; Sun, 16 Jan 2022 17:32:23 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id v2so2946401ply.11 for ; Sun, 16 Jan 2022 08:32:23 -0800 (PST) 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=RD3+fd1hRyTlaw48slzXvPuhXRYRbXB4aEVJbCou58o=; b=FOjgXkg42Bh2zlHpXUWhO1rFETEMQMxE6lYzw/0jJmZGdJi6BCyRAbP/+Xzq/3Cvdl Xi7yAZDWrFWuXbH+TGlB4iNmMVYJMbPThCf45K7sBF0NCkKslgIh6p300kY8msMzZjUx EVe+rm7HqHmIQh9j5czH2ASTig7c5YX0asKhRHrbsNmyDxu2IA47qEq+yuJAELHKNN/H IPMDK8XQpBDwQ5QkCmYKjQf7TxCvFlW3maQzaeEIKbARqA8ttRaQk/uNarfxIj88Al8G VXevTPLfk41Q3/UB5jIMMmpwTpFt9wF5Qi7BMqlkE3ykDGiqY9KK30RXgELXFJjxdSRx DYqw== 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=RD3+fd1hRyTlaw48slzXvPuhXRYRbXB4aEVJbCou58o=; b=weP9+j/Cf5FVCSwcFrumgsQR5w28X/AmYZozej5xRSqPHjPBZwdDQvsYX1NzZFCFq5 tmdwHMqQ4A0NgxrIHeY5/RmZpAie16MsJLT5Nu05QYdY3XWPaZuGJ1tqlg7iao/IXTpM sby4On+MgDhVw95cC9w9hLjsDc3Lvd4z+zc1LBXrYGOcCaL3MXMo72HI17IilVYJysm/ /w3SQxK99xCFLfmfEI+t4PWVr0G6nRHpteAqTvr6mINPjDhRaZ+g/Tr6bW/BLZ/Q3VTI BnskD7oSHfGW5Rnyw4n3poCHKW9zBA3HItbToMZyLlA8vYfxfOyYzQUZWpPOc9D6FyTG r5wg== X-Gm-Message-State: AOAM532MHVedHvg34g45Kyx5hPKy/TjwDYW/qySn3MlpSblto3IrHlFt jXUBEYKLaQmfFAkHPswwK8nauA== X-Google-Smtp-Source: ABdhPJzrV39K1FEJMkIW5Xy2XACXik9V5b3z+/kXNO4acjUkYTQBtskXCRC1ikE3Qo6dDXCFK0YvVQ== X-Received: by 2002:a17:90a:7c0f:: with SMTP id v15mr9490598pjf.7.1642350743164; Sun, 16 Jan 2022 08:32:23 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id b12sm12260974pfv.148.2022.01.16.08.32.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jan 2022 08:32:22 -0800 (PST) Date: Sun, 16 Jan 2022 08:32:20 -0800 From: Stephen Hemminger To: Luc Pelletier Cc: bruce.richardson@intel.com, konstantin.ananyev@intel.com, dev , Xiaoyun Li , dpdk stable Subject: Re: [PATCH v2] eal: fix unaligned loads/stores in rte_memcpy_generic Message-ID: <20220116083220.2abe11b2@hermes.local> In-Reply-To: References: <20220115194102.444140-1-lucp.at.work@gmail.com> <20220115213949.449313-1-lucp.at.work@gmail.com> <20220115141342.396a5f3a@hermes.local> 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 Sun, 16 Jan 2022 09:09:49 -0500 Luc Pelletier wrote: > > X86 always allows unaligned access. Irregardless of what tools say. > > Why impose additional overhead in performance critical code. > > Let me preface my response by saying that I'm not a C compiler developer. > Hopefully someone who is will read this and chime in. > > I agree that X86 allows unaligned store/load. However, the C standard doesn't, > and says that it's undefined behavior. This means that the code relies on > undefined behavior. It may do the right thing all the time, almost all the time, > some of the time... it's undefined. It may work now but it may stop > working in the future. > Here's a good discussion on SO about unaligned accesses in C on x86: > > https://stackoverflow.com/questions/46790550/c-undefined-behavior-strict-aliasing-rule-or-incorrect-alignment/46790815#46790815 > > There's no way to do the unaligned store/load in C (that I know of) > without invoking > undefined behavior. I can see 2 options, either write the code in > assembly, or use > some other C construct that doesn't rely on undefined behavior. > > While the for loop may seem slower than the other options, it > surprisingly results in > fewer load/store operations in certain scenarios. For example, if n == > 15 and it's > known at compile-time, the compiler will generate 2 overlapping qword load/store > operations (rather than the 4 that are currently being done with the > current code). > > All that being said, I can go back to something similar to my first > patch. Using inline > assembly, and making sure this time that it works for 32-bit too. I > will post a patch in > a few minutes that does exactly that. Maintainers can then chime in > with their preferred > option. I would propose that DPDK have same kind of define as the kernel for SAFE_UNALIGNED_ACCESS. The C standard has to apply to all architectures but DPDK will make the choice to be fast rather than standards conformant.