Bug 208803 - ixgbe(4) reports wrong IPv4 checksum when txcsum is enabled
Summary: ixgbe(4) reports wrong IPv4 checksum when txcsum is enabled
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords: IntelNetworking
Depends on:
Blocks:
 
Reported: 2016-04-14 15:35 UTC by n+freebsd
Modified: 2017-12-14 19:27 UTC (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description n+freebsd 2016-04-14 15:35:09 UTC 
I've got Silicom 10G Ethernet cards, which use the ixgbe(4) driver. When txcsum is enabled, outgoing IPv4 packets show up in tcpdump on the sending host as having a wrong checksum. However the packets appear to be sent with the correct checksum. On the receiving host, no checksum errors are detected.

I've tested this with multiple different cards (single port and dual port) on different machines. pciconf shows them as:

ix0@pci0:12:0:0:        class=0x020000 card=0xa05f8086 chip=0x10c78086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82598EB 10-Gigabit AF Network Connection'
    class      = network
    subclass   = ethernet
Comment 1 Hiren Panchasara freebsd_committer freebsd_triage 2016-04-14 16:44:06 UTC 
I think you are offloading checksuming with 'txcsum' flag to the card so tcpdump would not know the correct value and report the error. Receiving host not complaining also explains that. You can ignore that error/warning from tcpdump.
Comment 2 n+freebsd 2016-04-14 17:15:56 UTC 
I've also tested this
1) on Linux with the same card,
2) on FreeBSD with a Neterion Xframe II, which is rather old but supports txcsum according to ifconfig,
3) on FreeBSD with the Silicom cards but instead with TCP over IPv6,
all with no checksum errors.
Comment 3 Jeb Cramer 2016-09-15 18:53:25 UTC 
I'm not understanding what the bug is here.  tcpdump, on the transmit side, captures packets before they reach the hardware.  If hardware checksum offloading is enabled, the checksum value as reported by the stack (and thus tcpdump) is bogus because the stack didn't do the calculation.  The hardware will take care of the checksum when the stack passes the packet to the hardware (via the driver).

If you're concerned about the difference between FreeBSD and Linux, that might be worth exploring for future performance enhancements of the stack, if it makes sense.  The Linux networking stack seems to calculate IPv4 checksums, regardless.  And that would be why the checksum is reported correctly on tcpdump.  A few memory reads...a couple folds for calculating the checksum...perhaps the number of instructions for this isn't too expensive in their opinion?  I don't know.

I'm confused on #2.  Are you seeing the same behavior as the 82598?  Or are you seeing the checksum reported correctly?  If the former, then they probably have the same hardware feature.  If the latter, I don't have an answer.

#3 isn't any different than the IPv4 case.  Hardware will take care of the checksum calculation.
Comment 4 Eugene Grosbein 2016-09-15 19:30:07 UTC 
As noted above, this is expected behaviour when txcsum is not disabled.

This PR should be closed (not a bug).