From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: 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 To: Julien Castets Cc: users@dpdk.org, dev@dpdk.org Date: Wed, 07 Jun 2017 16:39:49 +0200 Message-ID: <2411222.g8kaCR81iN@xps> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-users] Invalid TCP/UDP checksum for IPV4 packets X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.