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 10405A04A7; Tue, 25 Jan 2022 08:59:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 835FE41238; Tue, 25 Jan 2022 08:59:24 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 0C9C04013F for ; Tue, 25 Jan 2022 08:59:24 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v2] eal: fix unaligned loads/stores in rte_memcpy_generic X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 25 Jan 2022 08:59:21 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86E3A@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v2] eal: fix unaligned loads/stores in rte_memcpy_generic Thread-Index: AdgReSmB1S0ec01PRq6E1wkglAjFogAQCAdQ References: <20220116083220.2abe11b2@hermes.local> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Georg Sauthoff" , "Stephen Hemminger" Cc: "Luc Pelletier" , , , "dev" , "Xiaoyun Li" 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 > From: Georg Sauthoff [mailto:mail@gms.tf] > Sent: Tuesday, 25 January 2022 00.22 >=20 > Hello, >=20 > Stephen Hemminger wrote (Sun, 16 Jan 2022 08:32:20 -0800): >=20 > > 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. >=20 > 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. >=20 > In contrast, DPDK isn't compiled with -fno-strict-aliasing, in = general. > Only a few drivers are built with -Wno-strict-aliasing. >=20 > Thus, one has to be careful when importing (or being inspired) by the > above mentioned kernel defines. >=20 > 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. >=20 > 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. Generally, I have an extremely strong preference for being able to = compile code with all warnings enabled in the compiler (-Wall and then = some). This gives the developer a great bug-detector tool (through the = compiler warnings). In my experience, compiling a Linux loadable module with all warnings = enabled spews out too many warnings about the kernel itself to be = helpful. This stems from bad practice, which should not be adopted by = DPDK. >=20 > 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. >=20 > BTW, are there still systems that DPDK supports but have a memcpy() > which > performs worse than rte_memcpy()? Excellent question! I have also seen memmove() being replaced with a = comment about some systems using temporary memory for their = implementation of memmove(). And most DPDK core libraries implement = their own copy functions - following the general DPDK advice not to use = standard C library functions. It's a shame there's no documentation why = all this was re-implemented in DPDK, so it can be checked if it is still = relevant or could be removed. >=20 >=20 > Best regards, > Georg