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 46E05A00C5; Mon, 6 Jul 2020 09:46:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 51FB01D678; Mon, 6 Jul 2020 09:46:34 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id 4342A1D678 for ; Mon, 6 Jul 2020 09:46:32 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id f7so36698865wrw.1 for ; Mon, 06 Jul 2020 00:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=HBXNcMLW1hWb2Gez1g0/+XOVGcmr0SZoaENBEFqlcGQ=; b=DDCeNjyBiQGY3cbzEarjGdWD8i0hkziheId/mdRO7pJjaxGN9NEBO/XcS1J6KAcS6Z RT6VC+uE0o5uJLZTgOyo3mzlOX4OZcbbNpRagsUrygpjtqqkNDm+IQZVHOOtRLlMIbsY wIG76dqbZh4bNQbeUWUNODvXOypCpO/4DKVZlz1+NYnjbbGPFFIAGHwf66wT64/oicjQ jvdaQYqvTY1CWe2U2oOPj9VR+iO5MZdTEY0JtA8FNc7rXeQES5zA/bQkvRt8nw+orKvK G9ZthZjI0KLC/pQq8S7q0FkOhDDSgoTdWILpXOdrM+ehCPeQDcS0nfuDT/q7vfM6EQqT t6BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=HBXNcMLW1hWb2Gez1g0/+XOVGcmr0SZoaENBEFqlcGQ=; b=ABKPvdWjLvAr8CjzH5LOOSlCdeKBiSkC/AKUReQh4qYUihPIIRAYMqIuf2xo2OHBGS e74jbY7u9E9Eeraozv+DPi40alUFjy1FZMdwZRHgBBwivQzmW1q0J437qjhgBvnIJC0k L2a+VnY/C20+/avmyDdMgqNgWXfGAptaYo5pbgSnDWcikEukkY0nqnj7ACG3xXYthV07 3cMzYJh1SHjLVWejsBhCRpnegLhptDs9JjNxNCJhWVD/LZJBsNVT1EB73U7OwqTmDRVs VPPJWb/KTuP82+/bwrnnqIo//IXK+jfRVXYnprRplnEwRO2mEICuHtQrJQNwwfBBrXQI TyDQ== X-Gm-Message-State: AOAM530KTJpKTybJr17PjxjN/OtxicGWE2EFROWWSMRSoEC2UAfzv3JN PzwKwvXkjTD4GXFjyuZJR4bE6w== X-Google-Smtp-Source: ABdhPJwk/XVCqRXspuvQH+htPrfny1YxY4ROY8oBBXHM0slXW3qMun+JgvszO1HxvK4cUb4dGmUEwA== X-Received: by 2002:a5d:5587:: with SMTP id i7mr45815887wrv.314.1594021591851; Mon, 06 Jul 2020 00:46:31 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id a3sm21721862wmb.7.2020.07.06.00.46.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2020 00:46:31 -0700 (PDT) Date: Mon, 6 Jul 2020 09:46:31 +0200 From: Olivier Matz To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Thomas Monjalon , guohongzhi1@huawei.com, dev@dpdk.org, stable@dpdk.org, 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 Message-ID: <20200706074631.GB5869@platinum> References: <20200527134009.19444-1-guohongzhi1@huawei.com> <2108086.oFbrkSXBjQ@thomas> <98CBD80474FA8B44BF855DF32C47DC35C610BA@smartserver.smartshare.dk> <7893780.fyxb4ROZLc@thomas> <98CBD80474FA8B44BF855DF32C47DC35C610BB@smartserver.smartshare.dk> <20200706073625.GA5869@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200706073625.GA5869@platinum> User-Agent: Mutt/1.10.1 (2018-07-13) 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" On Mon, Jul 06, 2020 at 09:36:25AM +0200, Olivier Matz wrote: > Hi Hongzhi, > > I suggest the following title instead: > > net: fix checksum on big endian CPUs > > On Wed, Jun 24, 2020 at 05:11:19PM +0200, Morten Brørup wrote: > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > > Sent: Wednesday, June 24, 2020 5:04 PM > > > > > > 24/06/2020 15:00, Morten Brørup: > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > Sent: Wednesday, June 24, 2020 2:22 PM > > > > > > > > > > 27/05/2020 15:40, guohongzhi: > > > > > > From: Hongzhi Guo > > > > > > > > > > > > __rte_raw_cksum should consider Big Endian. > > > > > > > > > > We need to explain the logic in the commit log. > > Here is a suggestion of commit log: > > With current code, the checksum of odd-length buffers is wrong on > big endian CPUs: the last byte is not properly summed to the > accumulator. > > Fix this by left-shifting the remaining byte by 8. For instance, > if the last byte is 0x42, we should add 0x4200 to the accumulator > on big endian CPUs. > > This change is similar to what is suggested in Errata 3133 of > RFC 1071. > > Can you please submit a new version with the 2 changes above? One more thing, please also add: Fixes: 6006818cfb26 ("net: new checksum functions") Cc: stable@dpdk.org Thanks Olivier > > > > > > > > > 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 the last byte. (Not really anymore, but back when little > > > endian was unfamiliar to me I would have struggled.) > > > > > > > > An RFC (I can't remember which) describes why the same checksum > > > calculation code works on both big and little endian CPUs. Is it this > > > explanation you are asking for? > > > > > > This explanation may be interesting. > > > > > > > RFC 1071, especially chapter 3. > > > > Please note that big endian is considered "Normal" order in the RFC. :-) > > There is an errata for this RFC about the C code: > see https://www.rfc-editor.org/errata/eid3133 > > > > > > > > > > Signed-off-by: Hongzhi Guo > > > > > > --- > > > > > > +#if (RTE_BYTE_ORDER == RTE_BIG_ENDIAN) > > > > > > + sum += *((const uint8_t *)u16_buf) << 8; > > > > > > +#else > > > > > > sum += *((const uint8_t *)u16_buf); > > > > > > +#endif > > > > > > > > > > *((const uint8_t *)u16_buf) should be an uint8_t. > > > > > What is the expected behaviour of shifting 8 bits of a byte? > > > > > > > > Yes, the value will be an uint8_t type. But the shift operation will > > > cause the compiler to promote the type to int before shifting it. > > > > > > This is the explanation I was looking for :-) > > > > > > > >