From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 86BF22B99 for ; Tue, 2 Apr 2019 09:59:05 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 656A5800079; Tue, 2 Apr 2019 07:59:03 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Apr 2019 08:58:57 +0100 To: "N. Benes" , dev References: <65744706-bc88-f144-f85e-1b0292402cff@eso.org> CC: Olivier Matz , Stephen Hemminger , Thomas Monjalon From: Andrew Rybchenko Message-ID: <105860ec-b4b7-b045-05e0-6fb67bab237a@solarflare.com> Date: Tue, 2 Apr 2019 10:58:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <65744706-bc88-f144-f85e-1b0292402cff@eso.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24526.003 X-TM-AS-Result: No-1.517100-8.000000-10 X-TMASE-MatchedRID: csPTYAMX1+EOwH4pD14DsPHkpkyUphL9f6/Md8Lb2l/VHyARSied1Cf+ fye9oWdYRgMywISTZ7LL3WQGGSY9Biom8dL6q+eLx+NP8E9qQHedwomSL6ihHTnZfxjBVQRbD5x YesPBpczY6QM2so1boqTjzAbcQdCBhPc4FTJN6V7PmvnL2ai5IO4dka7Cjort3XgCp7wTMXzfaQ v/F9hswCl2qx5RQ0VTkZOl7WKIImrvXOvQVlExsNAtbEEX0MxBxEHRux+uk8hxKpvEGAbTDkrTx NdWq3lYF56kqnMl4HL5b7+ctkvEMSczf3+zfIxNr9VpdkJziDDNn16zqXWNbPLILr9SxOglOvJA ZnttXY/sO5j+zy53FtQ17CngTb9OBKmZVgZCVnezGTWRXUlrx+EijnvekEIH X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--1.517100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24526.003 X-MDID: 1554191944-SbNYKkhJzKTQ Subject: Re: [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: , X-List-Received-Date: Tue, 02 Apr 2019 07:59:05 -0000 Hi, added more people in CC. On 4/1/19 6:29 PM, N. Benes wrote: > 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. I agree that it looks like a bug in DPDK. RFC 791 says nothing about avoid zero value for IPv4 checksum. Andrew. 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 3D20AA0679 for ; Tue, 2 Apr 2019 09:59:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F151C2E81; Tue, 2 Apr 2019 09:59:06 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 86BF22B99 for ; Tue, 2 Apr 2019 09:59:05 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 656A5800079; Tue, 2 Apr 2019 07:59:03 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Apr 2019 08:58:57 +0100 To: "N. Benes" , dev References: <65744706-bc88-f144-f85e-1b0292402cff@eso.org> CC: Olivier Matz , Stephen Hemminger , Thomas Monjalon From: Andrew Rybchenko Message-ID: <105860ec-b4b7-b045-05e0-6fb67bab237a@solarflare.com> Date: Tue, 2 Apr 2019 10:58:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <65744706-bc88-f144-f85e-1b0292402cff@eso.org> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24526.003 X-TM-AS-Result: No-1.517100-8.000000-10 X-TMASE-MatchedRID: csPTYAMX1+EOwH4pD14DsPHkpkyUphL9f6/Md8Lb2l/VHyARSied1Cf+ fye9oWdYRgMywISTZ7LL3WQGGSY9Biom8dL6q+eLx+NP8E9qQHedwomSL6ihHTnZfxjBVQRbD5x YesPBpczY6QM2so1boqTjzAbcQdCBhPc4FTJN6V7PmvnL2ai5IO4dka7Cjort3XgCp7wTMXzfaQ v/F9hswCl2qx5RQ0VTkZOl7WKIImrvXOvQVlExsNAtbEEX0MxBxEHRux+uk8hxKpvEGAbTDkrTx NdWq3lYF56kqnMl4HL5b7+ctkvEMSczf3+zfIxNr9VpdkJziDDNn16zqXWNbPLILr9SxOglOvJA ZnttXY/sO5j+zy53FtQ17CngTb9OBKmZVgZCVnezGTWRXUlrx+EijnvekEIH X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--1.517100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24526.003 X-MDID: 1554191944-SbNYKkhJzKTQ Subject: Re: [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: <20190402075852.uR8GedTrDwXiRcwaUaLMxP4xip3bqxHwWPFQObslYhw@z> Hi, added more people in CC. On 4/1/19 6:29 PM, N. Benes wrote: > 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. I agree that it looks like a bug in DPDK. RFC 791 says nothing about avoid zero value for IPv4 checksum. Andrew.