From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.ord1c.emailsrvr.com (smtp121.ord1c.emailsrvr.com [108.166.43.121]) by dpdk.org (Postfix) with ESMTP id BBEA7E62 for ; Wed, 28 Oct 2015 08:20:00 +0100 (CET) Received: from smtp8.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 38FCB804D6; Wed, 28 Oct 2015 03:20:00 -0400 (EDT) Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: padam.singh-AT-inventum.net) with ESMTPSA id 5AD298049A; Wed, 28 Oct 2015 03:19:59 -0400 (EDT) X-Sender-Id: padam.singh@inventum.net Received: from [172.16.1.231] ([UNAVAILABLE]. [103.25.205.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.4.2); Wed, 28 Oct 2015 07:20:00 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Padam Jeet Singh In-Reply-To: <20151028065757.GA4251@mhcomputing.net> Date: Wed, 28 Oct 2015 12:49:56 +0530 Content-Transfer-Encoding: quoted-printable Message-Id: <546F571B-8603-4D0E-95B3-6CE5BAD3EE02@inventum.net> References: <9E9D668A-17B5-4047-85B3-13519F898467@inventum.net> <20151028065757.GA4251@mhcomputing.net> To: Matthew Hall X-Mailer: Apple Mail (2.2070.6) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Wrong TCP Checkum computed by hardware X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 07:20:00 -0000 On 28-Oct-2015, at 12:27 pm, Matthew Hall wrote: >=20 > On Wed, Oct 28, 2015 at 12:20:22PM +0530, Padam Jeet Singh wrote: >> Any hint what could I be doing wrong here? >=20 > When this kind of stuff doesn't work it often will depend on the exact = version=20 > of card, chip, etc. if there are any errata. >=20 82599ES or ixgbe PMD has not had any bug fixes related to offload - not = at least what I can see in the git commits. One important finding: Issue only comes when I do TX VLAN offload using = PKT_TX_VLAN_PKT (fill vlan tci, l2_len, l3_len with the VLAN ID, = sizeof(struct ether_hdr), sizeof(struct ipv4_hdr) respectively. So basically VLAN OFFLOAD + IP CSUM OFFLOAD + TCP CSUM OFFLOAD causes = the TCP checksum to be computed wrong. VLAN Offload + IP CSUM Offload + = TCP CSUM in Software produces correct results. I am suspecting this to = be ixgbe driver bug now as nothing in my code can trigger this = behaviour. > So you might want to collect the specifics of the board with lspci -v,=20= > ethtool, and pulling it out to check the chip and board revisions. 02:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit = SFI/SFP+ Network Connection (rev 01) Flags: bus master, fast devsel, latency 0, IRQ 32 Memory at c7d20000 (64-bit, non-prefetchable) [size=3D128K] Memory at c7d44000 (64-bit, non-prefetchable) [size=3D16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=3D1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable+ Count=3D64 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [e0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-90-0b-ff-ff-3f-19-d0 Capabilities: [150] Alternative Routing-ID Interpretation (ARI) Capabilities: [160] Single Root I/O Virtualization (SR-IOV) Kernel driver in use: igb_uio Kernel modules: ixgbe >=20 > In addition check over the example apps and see how things work there = compared=20 > with your own code. Often the DPDK interfaces are kind of complex and = small=20 > pointer or mbuf manipulation mistakes can cause very odd results. >=20 None of the sample code addresses the scenario which I have =3D VLAN = offload + IP + TCP offload. > Matthew. Thanks, Padam