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 5225CA04A3; Tue, 25 Jan 2022 00:21:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C5F45410EC; Tue, 25 Jan 2022 00:21:45 +0100 (CET) Received: from turing.lru.li (turing.lru.li [49.12.115.177]) by mails.dpdk.org (Postfix) with ESMTP id A59134069F for ; Tue, 25 Jan 2022 00:21:43 +0100 (CET) Received: from dell12.lru.li (unknown [IPv6:2001:1a80:303a:0:fc99:3b2a:af4a:60d4]) (Authenticated sender: georg) by turing.lru.li (Postfix) with ESMTPSA id 563C5A804CC; Mon, 24 Jan 2022 23:21:43 +0000 (UTC) Received: by dell12.lru.li (Postfix, from userid 1000) id D16ED11B8AE; Tue, 25 Jan 2022 00:21:42 +0100 (CET) Date: Tue, 25 Jan 2022 00:21:42 +0100 From: Georg Sauthoff To: Stephen Hemminger Cc: Luc Pelletier , bruce.richardson@intel.com, konstantin.ananyev@intel.com, dev , Xiaoyun Li , Morten =?iso-8859-1?Q?Br=F8rup?= Subject: Re: [PATCH v2] eal: fix unaligned loads/stores in rte_memcpy_generic Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220116083220.2abe11b2@hermes.local> 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 Hello, Stephen Hemminger wrote (Sun, 16 Jan 2022 08:32:20 -0800): > 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. perhaps it's worth mentioning that the Linux Kernel is compiled with -fno-strict-aliasing, because it contains code which violates the C strict aliasing rules. Such code yields undefined behavior and is thus unsafe when compiling with optmizing compilers such as GCC and Clang, by default. But since the Linux supplies -fno-strict-aliasing its code is safe, in the Linux Kernel context. In contrast, DPDK isn't compiled with -fno-strict-aliasing, in general. Only a few drivers are built with -Wno-strict-aliasing. Thus, one has to be careful when importing (or being inspired) by the above mentioned kernel defines. Especially, it looks like version 5 of this patch yields undefined behavior because it violates strict-aliasing rules. It's possible that GCC makes some extra guarantees for the used constructs, even when compiling without -fno-strict-aliasing. But I'm not aware of any. Please note that there is a reason GCC enables -fstrict-aliasing when compiling with optimizations: Performance IOW, -fno-strict-aliasing has performance implications, thus one is advised to not use it, if possible. IOW, when violating strict-aliasng rules one can easily end up with low-performing and/or unsafe (buggy) code. I haven't inspected the DPDK drivers which supply -Wno-strict-aliasing - but I wouldn't be surprised if there aren't better alternatives. Meaning writing the code in a way that doesn't require -Wno-strict-aliasing. BTW, are there still systems that DPDK supports but have a memcpy() which performs worse than rte_memcpy()? Best regards, Georg