From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by dpdk.space (Postfix) with ESMTP id 748EAA0679
	for <public@inbox.dpdk.org>; Fri,  5 Apr 2019 11:31:19 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 60FB61B494;
	Fri,  5 Apr 2019 11:31:18 +0200 (CEST)
Received: from hqmgw2.hq.eso.org (hqmgw2.hq.eso.org [134.171.42.202])
 by dpdk.org (Postfix) with ESMTP id 6477B1B48C
 for <users@dpdk.org>; Fri,  5 Apr 2019 11:31:17 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="5.60,312,1549926000"; d="scan'208";a="47310261"
Received: from mxroute02.hq.eso.org ([134.171.15.34])
 by hqmgw2.hq.eso.org with ESMTP; 05 Apr 2019 11:31:17 +0200
Received: from mxadauth01.hq.eso.org (mxadauth01.hq.eso.org [134.171.42.78])
 by mxroute02.hq.eso.org (Postfix) with ESMTP id 01D1B120002;
 Fri,  5 Apr 2019 11:31:17 +0200 (CEST)
Received: from [127.0.0.1] (hq-000-kemp01.hq.eso.org [134.171.42.9])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested) (Authenticated sender: nbenes)
 by mxadauth01.hq.eso.org (Postfix) with ESMTPSA id F0840100D07;
 Fri,  5 Apr 2019 11:31:16 +0200 (CEST)
To: users@dpdk.org
References: <CAP-guGXWHNKvJ7F9WMP8b3-U9Qmu5Dk2wKRLu0Y9+DYvQFr3VQ@mail.gmail.com>
From: "N. Benes" <nbenes@eso.org>
Message-ID: <59ccc981-0231-afd4-5717-45fbaff09644@eso.org>
Date: Fri, 05 Apr 2019 09:31:00 +0000
MIME-Version: 1.0
In-Reply-To: <CAP-guGXWHNKvJ7F9WMP8b3-U9Qmu5Dk2wKRLu0Y9+DYvQFr3VQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-users] checksums?
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=subscribe>
Errors-To: users-bounces@dpdk.org
Sender: "users" <users-bounces@dpdk.org>

Hi,

William Herrin:
> Hi folks,
> 
> I've recently done a deep dive in to IP checksums and I've run in to
> something I don't understand. Any insight would be helpful.
> 
> rte_ipv4_cksum() is implemented as:
> 
> return (cksum == 0xffff) ? cksum : (uint16_t)~cksum;
> 
> Which means: if the sum is zero, return -0 (0xffff) never +0 (0x0000).
> Welcome to the wonderful world of 1's complement arithmetic.
> 
> RFC 1624, on the other hand, says:
> 
> "In one's complement, there are two representations of zero: the all zero
> and the all one bit values, often referred to as +0 and -0. One's
> complement addition of non-zero inputs can produce -0 as a result, but
> never +0.  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)."
> 
> Which I understand to mean that +0 (0x0000) is a legal value in an IPv4
> checksum field, but -0 (0xffff) is not.
> 
> Is this a bug? Is there a more authoritative source for which zero is
> correct in an IPv4 header? Please help me find the error in my
> understanding.
> 
> Thanks,
> Bill Herrin
> 
> 

Related threads:

https://mails.dpdk.org/archives/users/2019-March/004021.html
https://mails.dpdk.org/archives/dev/2019-April/128473.html

Cheers!