From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 070EA2BA1;
 Wed,  7 Jun 2017 16:39:50 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id A0B6420A37;
 Wed,  7 Jun 2017 10:39:50 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
 by compute1.internal (MEProxy); Wed, 07 Jun 2017 10:39:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=4HPkPhoNvti2tdk
 IN7R2cHbtbfYmrRCuroF8DpHh2PQ=; b=hKagEjUnFWFd1YfwwVoolQZYIFeZpGf
 vIGedmOPNl8st1Qnyyy1rjSt2z6MLETwAktRwbXQfIZ+ftJZjnEbrnEbIhbfb1rL
 hpGT+F1ZqONs253aOgbGgo6X0Siif7IYd2eu0p+jk2XyuLeg+iIPSBxmxkQvUidt
 PGOWVSAwsvQo=
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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s=
 fm1; bh=4HPkPhoNvti2tdkIN7R2cHbtbfYmrRCuroF8DpHh2PQ=; b=LvkNmrnR
 p+Gkn2Y7iwRqLI2+AccYDElLanYFn7ZccQY3qHjj690W0Dx+R5loYwXF6zxtNXtS
 n0vD/hzhrrj51rM7MlOr6BburB9v882rEKOEbA5nf/KJvMloMX44Nw5JX6YKMLPN
 hZe9jnhO3vOVB/WW1BqKYj6PV/WsW+t1/O0o5NtLSiJZIqaJewjFPqKeAafm6IzP
 5LexyKo4IWHoJha93ZhloKlrC2BWA5HFJBlKjOgJlh4D+FFrV/Cphtt5rxti8PJ9
 WIgW2+NZvrPrd+eVXgj99pTtOFDgIAOy4Y/j8aKoRqreiYHyHj0b8/zCa3Inwhqf
 BMhQNYBDxpDuOQ==
X-ME-Sender: <xms:NhA4WWWld0-87snuc5dVIlnPmpcpi9i_IvHI8U5ljn3VsoRIRzV6rA>
X-Sasl-enc: WMctAhsb5ZEEckP98Fx26aBT0Dbxn6OqRAVMomL6p6EL 1496846390
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 4F6CF7E815;
 Wed,  7 Jun 2017 10:39:50 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Julien Castets <castets.j@gmail.com>
Cc: users@dpdk.org, dev@dpdk.org
Date: Wed, 07 Jun 2017 16:39:49 +0200
Message-ID: <2411222.g8kaCR81iN@xps>
In-Reply-To: <CADF714Y-eLGjjV3CLmGNvE=fu9YKh7EeZspMK6WfyP2hU3qR2A@mail.gmail.com>
References: <CADF714Y-eLGjjV3CLmGNvE=fu9YKh7EeZspMK6WfyP2hU3qR2A@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [dpdk-users] Invalid TCP/UDP checksum for IPV4
	packets
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2017 14:39:51 -0000

Hi,

31/05/2017 10:16, Julien Castets:
> I had a running application on DPDK 2.2.0 which offloads IP/TCP/UDP
> checksums to the NIC. A few days ago, I started the migration to 17.02
> and started to see invalid TCP/UDP checksum.
> 
> I called the new API rte_eth_tx_prepare() but checksums were still invalid.
> 
> After digging for a few hours in DPDK source code, I discovered the
> flag PKT_TX_IPV4 needs to be set in ol_flags.
> 
> Basically, the function rte_net_intel_cksum_flags_prepare of rte_net.h
> (http://dpdk.org/doc/api/rte__net_8h_source.html) does the following:
> 
> if (offload TCP checksum flag is set) {
>   if (PKT_TX_IPV4 in ol_flags) {
>      // compute ipv4 checksum
>    }
>    else {
>      // compute ipv6 checksum
>    }
> }
> 
> Because I didn't set PKT_TX_IPV4 in ol_flags, I was going into the
> "else" clause and the checksum was computed as if my packet was an
> IPV6 packet.
> 
> Don't you think it would be preferable to assert instead of
> considering a non-explicitely-declared-IPV4-packet as being an IPV6
> packet?

Yes, you're right.
I think we were avoiding wasting 1 cycle here.
Usability was the cost for best performance.
A good trade-off may be to use RTE_ASSERT which will be triggered only
in debug mode.