From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 538E5A0679 for ; Mon, 1 Apr 2019 17:29:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 27800378E; Mon, 1 Apr 2019 17:29:54 +0200 (CEST) Received: from hqmgw2.hq.eso.org (hqmgw2.hq.eso.org [134.171.42.202]) by dpdk.org (Postfix) with ESMTP id BC7C32B99 for ; Mon, 1 Apr 2019 17:29:52 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.60,297,1549926000"; d="scan'208";a="47267616" Received: from mxroute02.hq.eso.org ([134.171.15.34]) by hqmgw2.hq.eso.org with ESMTP; 01 Apr 2019 17:29:51 +0200 Received: from mxadauth03.hq.eso.org (mxadauth03.hq.eso.org [134.171.42.80]) by mxroute02.hq.eso.org (Postfix) with ESMTP id DB30F120002; Mon, 1 Apr 2019 17:29:51 +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 mxadauth03.hq.eso.org (Postfix) with ESMTPSA id D55D320B52; Mon, 1 Apr 2019 17:29:51 +0200 (CEST) To: dev From: "N. Benes" Message-ID: <65744706-bc88-f144-f85e-1b0292402cff@eso.org> Date: Mon, 01 Apr 2019 15:29:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] Bug in IPv4 header checksum computation? 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" Message-ID: <20190401152900.wTtLiTYj7qhFgiR_HYwQH9R2XY0x8bExBtL2jX-5H5k@z> Hi, I wrote to the users list a bit more a week ago concerning the IPv4 Header Checksum computation and received no comments on it yet: https://mails.dpdk.org/archives/users/2019-March/004021.html https://mails.dpdk.org/archives/users/2019-March/004022.html I have the impression that the current implementation wrongly does a conditional final inversion of the computed sum. This is correct for e.g. UDP, but I think it is not for an IPv4 Header (header checksum is not optional). If it is a bug, this could result in a surprisingly high number of invalid/dropped IPv4 packets, when the checksum is calculated manually via the DPDK API (not NIC-offloaded) and the IPv4 header has an appropriate combination of values e.g. the IP Identification field. Cheers!