From: Padam Jeet Singh <padam.singh@inventum.net>
To: Matthew Hall <mhall@mhcomputing.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Wrong TCP Checkum computed by hardware
Date: Wed, 28 Oct 2015 12:49:56 +0530 [thread overview]
Message-ID: <546F571B-8603-4D0E-95B3-6CE5BAD3EE02@inventum.net> (raw)
In-Reply-To: <20151028065757.GA4251@mhcomputing.net>
On 28-Oct-2015, at 12:27 pm, Matthew Hall <mhall@mhcomputing.net> wrote:
>
> On Wed, Oct 28, 2015 at 12:20:22PM +0530, Padam Jeet Singh wrote:
>> Any hint what could I be doing wrong here?
>
> When this kind of stuff doesn't work it often will depend on the exact version
> of card, chip, etc. if there are any errata.
>
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,
> 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=128K]
Memory at c7d44000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=64 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
>
> In addition check over the example apps and see how things work there compared
> with your own code. Often the DPDK interfaces are kind of complex and small
> pointer or mbuf manipulation mistakes can cause very odd results.
>
None of the sample code addresses the scenario which I have = VLAN offload + IP + TCP offload.
> Matthew.
Thanks,
Padam
next prev parent reply other threads:[~2015-10-28 7:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 6:50 Padam Jeet Singh
2015-10-28 6:57 ` Matthew Hall
2015-10-28 7:19 ` Padam Jeet Singh [this message]
2015-10-28 8:01 ` Liu, Jijiang
2015-10-28 8:12 ` Padam Jeet Singh
2015-10-28 8:16 ` Liu, Jijiang
2015-10-28 8:30 ` Padam Jeet Singh
2015-10-28 8:34 ` Liu, Jijiang
2015-10-28 11:02 ` Padam Jeet Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546F571B-8603-4D0E-95B3-6CE5BAD3EE02@inventum.net \
--to=padam.singh@inventum.net \
--cc=dev@dpdk.org \
--cc=mhall@mhcomputing.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).