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 3F194A0352; Tue, 8 Feb 2022 17:53:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F26B84111B; Tue, 8 Feb 2022 17:53:25 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id F065F4114D; Tue, 8 Feb 2022 17:53:24 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 99B655C007D; Tue, 8 Feb 2022 11:53:24 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 08 Feb 2022 11:53:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=WdFZvQssMkAqWU /ip1cY/cyFhGAHVD6YDNUZbyPnx1w=; b=evHaWTW1zp9NdtfwENeYAxuTKd13J0 HsbogISnNSU4J9P9Z+UvCOnx9A/GOStlKCu+YZhRwYU4ggreNd6y+n909e3rku26 oqIT2OXZr4b/MX4VAGt31pH7jRCDgKx8mpXGzeC3zVhraT2lNCBOpV6QDC264xI2 0hOaN7vTZrD1rDatjo6RN5k6HV676ryD+jF/gS+ZLvM9nYsd4dDWV6Z9KhkpJRVp D5oj8ERxdfmeTwjZL0u4TeLBpI17zRbOZbs5k2yv7QtdUsrWvDraMmS8zNeNWpiL gJtfWZUl+p0gSn05AgJmngiIS5ZKneJVUhMlFtzaQks++tPW6A2cS8og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=WdFZvQssMkAqWU/ip1cY/cyFhGAHVD6YDNUZbyPnx 1w=; b=iVUvdYhzNR8mrCANhr6mkfaESsivmB/NefiOvw+xlHvT4Q5ZNc7QhNAfv 1pY5901uAeFACN6rgzyODSCZW+cosTkRDDYxuRu7CH5Aue7a/Ub8Q29g3kHFyMZ/ tTt0ypPpsqWbIeR4UNw+Bv/xAVcN+iAt3ybiu5gNx9mjuZSRMaSQ0sTfruGSOKi0 DPhuARRbgw+a2NYbqoI/y6jP1qupLhE3rSlWvY/Y3N3+nSSlLMGkAf3ZIK4wHBiO 1VYX71y2/bPCXdmnBFiWd68WWay71futtt6FJNKJ/FtWWiT7oIVCAybxBWavvza1 CVD/pOsXGcBaEiph/sD59A8frxKxA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheejgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Feb 2022 11:53:23 -0500 (EST) From: Thomas Monjalon To: "Richardson, Bruce" , "Li, Xiaoyun" , "Ananyev, Konstantin" Cc: Luc Pelletier , dev@dpdk.org, "stable@dpdk.org" , ferruh.yigit@intel.com, olivier.matz@6wind.com, stephen@networkplumber.org Subject: Re: [PATCH v5] eal: fix unaligned loads/stores in rte_memcpy_generic Date: Tue, 08 Feb 2022 17:53:22 +0100 Message-ID: <1851702.taCxCBeP46@thomas> In-Reply-To: References: <20220115194102.444140-1-lucp.at.work@gmail.com> <20220117153711.32829-1-lucp.at.work@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 04/02/2022 18:16, Ananyev, Konstantin: > > > Calls to rte_memcpy_generic could result in unaligned loads/stores for > > 1 < n < 16. This is undefined behavior according to the C standard, > > and it gets flagged by the clang undefined behavior sanitizer. > > > > rte_memcpy_generic is called with unaligned src and dst addresses. > > When 1 < n < 16, the code would cast both src and dst to a qword, > > dword or word pointer, without verifying the alignment of src/dst. The > > code was changed to use a packed structure to perform the unaligned > > load/store operations. This results in unaligned load/store operations > > to be C standards-compliant. > > Still not sure we need to fix that: > This is x86 specific code-path, and as I remember on x86 there are no > penalties for unaligned access to 2/4/8 byte values. > Though I like introduction of rte_mov15_or_less() function -t helps > with code dedup. Any more opinions?