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 CE2A3A0352; Thu, 14 May 2020 16:19:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 050081D973; Thu, 14 May 2020 16:19:37 +0200 (CEST) Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 4635C1D964 for ; Thu, 14 May 2020 16:19:35 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id n5so18003957wmd.0 for ; Thu, 14 May 2020 07:19:35 -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=lbeMTNh7V2uWhkp/bo0v1FPDXdW8F0ZJtvmX5oxPPJ0=; b=aXdryshZtOSa4Ic613BNPiMvaxBXcEmiGAVCdlk/qxu4iv0Ts7iAhHtOv0KCBxfNIG 38hTcGhOYlnZrvuQ/sfbmyQIndMfcAG2p/oMd4xkN+2fkuy99cMNU83J53LDhKtI85s7 Yqk6LgKtXXgJlhnKyg9zw97vzWafnYP3jggG0GyfND7f7ZvTF9OUnQRa0v8s0n1JZyyw bQfIXzQ1vK7lyKX81kv7s2YhxBUzPvpO2AZABdm5Ndq1NSiEpFSx0yYw/7toEiTxL0Am a0rK137XDbvAJcD9zSNNcbFjtGudAVpzA1DDJIfshgl19T0J7p+jlEHj9B4dzEJHaYhD slCA== 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=lbeMTNh7V2uWhkp/bo0v1FPDXdW8F0ZJtvmX5oxPPJ0=; b=S4IRkTCcK9Y3WqDrF1Yo0eoe6IMVl413ePU++PP1l8em8Q+OeD3wAcqWq2AiaTFmyV 0cuOextLYZRXjXrLIr91N3wJ5OQURvq6gfcGpwZkgJG8gBoHwOxCPahUlf+G7YLTi5z7 mAk+2+sVzguQJiHUgtpce5UAL9TbxfBZRArcAtQkYQGiGfL/M5QJa4DXbttdib1iGuHf jmZnllFkv8URjwir3+jupyE6gcVmLVue6yy41exwDrZzbINvESxf7/cl81M6lOrTqwwi BirAuw+gum114nUWsdOLbgMrvryU3oT9i5qJQgOhtjJf9NWbzI82VBgSdHkWh4t6Aq29 rQkg== X-Gm-Message-State: AOAM533rOmgmJTHd4v7RmmcO7q7RisukMjbMuqD5+4qtxdE5HUBLdvY4 VYicztO+A37oeidMG/oZZ/quwQ== X-Google-Smtp-Source: ABdhPJw+JTSyKn0ZO4mDiT0j9yEPnBNXrb1q16O9pD3KSRYpszYO5FkYzVOBRbS02ujIbA1/aquzcw== X-Received: by 2002:a1c:6383:: with SMTP id x125mr11755629wmb.165.1589465974861; Thu, 14 May 2020 07:19:34 -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 v8sm4215520wrs.45.2020.05.14.07.19.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2020 07:19:34 -0700 (PDT) Date: Thu, 14 May 2020 16:19:33 +0200 From: Olivier Matz To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: guohongzhi , dev@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, stable@dpdk.org Message-ID: <20200514141933.GE1739@platinum> References: <20200514012729.23920-1-guohongzhi1@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35C60FC4@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60FC4@smartserver.smartshare.dk> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH] lib/librte_net: fix bug for ipv4 checksumcalculating 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" Hi, On Thu, May 14, 2020 at 02:56:41PM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of guohongzhi > > Sent: Thursday, May 14, 2020 3:27 AM > > > > 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(like Trident3). > > > > 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). > > > > --- > > lib/librte_net/rte_ip.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h > > index 1ceb7b7..ece2e43 100644 > > --- a/lib/librte_net/rte_ip.h > > +++ b/lib/librte_net/rte_ip.h > > @@ -267,7 +267,7 @@ rte_ipv4_cksum(const struct rte_ipv4_hdr *ipv4_hdr) > > { > > uint16_t cksum; > > cksum = rte_raw_cksum(ipv4_hdr, sizeof(struct rte_ipv4_hdr)); > > - return (cksum == 0xffff) ? cksum : (uint16_t)~cksum; > > + return (uint16_t)~cksum; > > } > > > > /** > > -- > > 2.21.0.windows.1 > > > > > > Well spotted! Indeed. > Reviewed-By: Morten Brørup Fixes: 6006818cfb26 ("net: new checksum functions") Cc: stable@dpdk.org Acked-by: Olivier Matz > Would you consider writing another patch splitting > rte_ipv4_udptcp_cksum() up into rte_ipv4_udp_cksum() and > rte_ipv4_tcp_cksum(), so the TCP checksum will be calculated > correctly? > > RFC 768 for UDP specifies: > > If the computed checksum is zero, it is transmitted as all ones (the > equivalent in one's complement arithmetic). An all zero transmitted > checksum value means that the transmitter generated no checksum (for > debugging or for higher level protocols that don't care). > > RFC 793 for TCP has no such special treatment for the checksum of > zero, but rte_ipv4_udptcp_cksum() implements the UDP special treatment > anyway. I agree the following test is useless in case of TCPv4 and TCPv6: if (cksum == 0) cksum = 0xffff; For UDPv4, it is needed because 0 means "no checksum". For UDPv6, it is needed because 0 is forbidden. So yes, I think we could have specific csum functions for tcp and udp checksum as Morten suggests (as soon as we keep the backward compat).