From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C7C07A0350; Wed, 24 Jun 2020 17:04:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75C8E1D9DA; Wed, 24 Jun 2020 17:04:15 +0200 (CEST) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by dpdk.org (Postfix) with ESMTP id 233ED1D9D2; Wed, 24 Jun 2020 17:04:14 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 2A8407F2; Wed, 24 Jun 2020 11:04:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 24 Jun 2020 11:04:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= S4NqET+AyuawS3DqflL2ybYzTrzINxCxYhdd/FV8/ks=; b=SNC4eqAzmaMZ/IA8 bS8aSQFtxCs5olOy3MmDahAXGLRrP0d+OsG/5tfLBlC915+ARiN4ofRPzPsszpHd Z4u0lmYt7dyQBFIlE1OeNsw5FScuuP4Cqf7fOyAqU6YUDuETUbGdFMi5nMAzzQsc TSOIuOtMB6LcQQV8HuEWcwhSjsnqKfeXmiGwLzYsI7aWcslfWFpGbxrIuUfqaxJA TtHgYxsPeIi+F3j5MwepfwlaLUIoMs9YOKRBBxbE2Ka+EicTLxzCRXNhN3LGoZNe JJ/6nL2Il2YTtKrhbdY3Z3EyefJVG7ykN4I9WtMT1pVbTtClXuhFIG6LtgBtytOj Pna4hQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=S4NqET+AyuawS3DqflL2ybYzTrzINxCxYhdd/FV8/ ks=; b=t1NyQ/x91pLLmH+JIHb3a3Y9pL81MSzEeDSga6Kpl6tVfz+DdDbE937jo FxkkZTb7RT52lwCM1Vfc3cj5jsw2h6zRRxi5ye5g6clOpz8Tm2w0kIY+/21iDN/n cFy1JEG27JzKJrSAPIEagcDhaVsAMG79kNHquGWkK1PMyfe6POBML7WG3d4BIWe+ XlSdHuyRfSFJEoVyre/Ks88rXhGwzpopNiKhq8nPrxloL39VdNHftu9WqzwKfsBp 8X8E7mn9hxTAU13bnKDrj3/VV0t6PEy//9owx+zFn2H/wfiGX6aYzWlfgkbWEuwv q2OIiL5hV+UTbGbm93kDZRG1/wwTw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfeegffeihfeftedthfdvgfetkeffffdukeevtdevtddvgfevuedu veegvdeggedtnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 215AA306769C; Wed, 24 Jun 2020 11:04:09 -0400 (EDT) From: Thomas Monjalon To: guohongzhi1@huawei.com Cc: Morten =?ISO-8859-1?Q?Br=F8rup?= , dev@dpdk.org, stable@dpdk.org, olivier.matz@6wind.com, konstantin.ananyev@intel.com, jiayu.hu@intel.com, ferruh.yigit@intel.com, nicolas.chautru@intel.com, cristian.dumitrescu@intel.com, zhoujingbin@huawei.com, chenchanghu@huawei.com, jerry.lilijun@huawei.com, haifeng.lin@huawei.com Date: Wed, 24 Jun 2020 17:04:07 +0200 Message-ID: <7893780.fyxb4ROZLc@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C610BA@smartserver.smartshare.dk> References: <20200527134009.19444-1-guohongzhi1@huawei.com> <2108086.oFbrkSXBjQ@thomas> <98CBD80474FA8B44BF855DF32C47DC35C610BA@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] bugfix: rte_raw_checksum X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 24/06/2020 15:00, Morten Br=F8rup: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Wednesday, June 24, 2020 2:22 PM > >=20 > > 27/05/2020 15:40, guohongzhi: > > > From: Hongzhi Guo > > > > > > __rte_raw_cksum should consider Big Endian. > >=20 > > We need to explain the logic in the commit log. >=20 > Having grown up with big endian CPUs, reading the final byte like this is= obvious to me. I struggle understanding the little endian way of reading t= he last byte. (Not really anymore, but back when little endian was unfamili= ar to me I would have struggled.) >=20 > An RFC (I can't remember which) describes why the same checksum calculati= on code works on both big and little endian CPUs. Is it this explanation yo= u are asking for? This explanation may be interesting. > > > Signed-off-by: Hongzhi Guo > > > --- > > > +#if (RTE_BYTE_ORDER =3D=3D RTE_BIG_ENDIAN) > > > + sum +=3D *((const uint8_t *)u16_buf) << 8; > > > +#else > > > sum +=3D *((const uint8_t *)u16_buf); > > > +#endif > >=20 > > *((const uint8_t *)u16_buf) should be an uint8_t. > > What is the expected behaviour of shifting 8 bits of a byte? >=20 > Yes, the value will be an uint8_t type. But the shift operation will caus= e the compiler to promote the type to int before shifting it. This is the explanation I was looking for :-)