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 8962FA04A4; Sun, 24 May 2020 17:22:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3C4671C043; Sun, 24 May 2020 17:22:53 +0200 (CEST) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by dpdk.org (Postfix) with ESMTP id B84851C036 for ; Sun, 24 May 2020 17:22:51 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 0666C7A7; Sun, 24 May 2020 11:22:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 24 May 2020 11:22:50 -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= E6UtsBGv6WWS8v3xAdhFfwpsS+Dl427X9hWqDpaL290=; b=N17drr6H4kO2exua agj5eTMGo+KOsYd2vusYgKy0EGsWIKc9rMa2JhkfACnOMOS6MlWMO6MeKHCufcE4 EgSvRalGaCV3jDWFgm15qTcwaDnmqsDH0R6s9Z/QORbKTjSI5IMxzAGIgwht/3ea rnvaHmyk6iZNfsulTxwhrjJZKMpF2HkGIOMRutWbnuOF+w/A7VWLu6Ops9p2sUjF U7GtX0kdeyiT9AQ7g/KKQGNi1XfycynqNu9aUihaN3ctAmxH9zfbHa5ipFOktR3W QoWRIgaHr9GrxI/jG9gmhUrTv3EuiiE/htkccwwZhZTya2/cTjS5aKUYV71AIqNO GO0MFg== 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=fm2; bh=E6UtsBGv6WWS8v3xAdhFfwpsS+Dl427X9hWqDpaL2 90=; b=QcUIdMUNfijrj7xDu8mtPzHfYoB55p0geu2jZhi5gxq0l6LYeZZxiW0U6 EmwClguco7nuAwqsqTcbCwqIThUcBtH6a/98MGu0ezyfeloaxP4knMb+EAWytHLJ rN2jXlC89Ol6ksE70+mc1Xa9WHvS1jQOg+Fo05GTCW1qY+h7O4u0szvVpHh3ztFL cpSI+y6m59t19xWp6oSgDdo/GTMfoGT+qv7GhpABGwco1U7VmDI4r77WanVsA/sX bykUfaE8oF/qshPtBedN2Tl3ScPCEhF7eK7kBfv58gM9xFfLYELgq/4eBLaMvqhs ry7KSeJ+s7gPFFs6WiBUuRAifw2mw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddukedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfggfgtgesthhqre dttddtudenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshes mhhonhhjrghlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeelveetfeeifeelteevje evhfejieehheejgeejheekheeggfejleekkeeiveduteenucffohhmrghinhepihgvthhf rdhorhhgpdguphgukhdrohhrghenucfkphepjeejrddufeegrddvtdefrddukeegnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghs sehmohhnjhgrlhhonhdrnhgvth 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 7142C306651D; Sun, 24 May 2020 11:22:47 -0400 (EDT) From: Thomas Monjalon To: guohongzhi1@huawei.com Cc: dev@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: Sun, 24 May 2020 17:22:46 +0200 Message-ID: <1867789.0SWPrSUWr3@thomas> In-Reply-To: <20200514012729.23920-1-guohongzhi1@huawei.com> References: <20200514012729.23920-1-guohongzhi1@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH] lib/librte_net: fix bug for ipv4 checksum calculating 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" 14/05/2020 03:27, guohongzhi: > The function of rte_ipv4_cksum for calculating the > checksum of IPv4 header is incorrect. > This function will return checksum value like 0xffff. > This value, however, is considered an illegal checksum on some switches(l= ike Trident3). >=20 > RFC 1624 specifies the IPv4 checksum as follows: > https://tools.ietf.org/rfc/rfc1624 > Since there is guaranteed to be at least one > non-zero field in the IP header, and the checksum field in the > protocol header is the complement of the sum, the checksum field can > never contain ~(+0), which is -0 (0xFFFF). It can, however, contain > ~(-0), which is +0 (0x0000). >=20 > --- > lib/librte_net/rte_ip.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Suggested title: net: fix IPv4 checksum Please send a v2 with your full name and add a Signed-off-by line. You can check the contributing guidelines: http://core.dpdk.org/contribute/#send You need to add these lines from previous reviews: =46ixes: 6006818cfb26 ("net: new checksum functions") Cc: stable@dpdk.org Reviewed-By: Morten Br=F8rup Acked-by: Olivier Matz