7

In a work sheet for PCs that we deliver to customers, I found instructions to always "Disable TCP Checksum Offload" on the NICs. Via those NICs, the PCs are connected to the customer's LAN, and it is imperative that they work without problems.

The explanation by a seasoned colleague for why this instruction is needed was that "NICs are always buggy and are causing lots of problems because of this."

Now, I could just imagine that they've had such problems a couple of years ago and have been doing things this way ever since.

But since the offload is usually on by default, I could also imagine that the NICs we get these days have improved somewhat. Also, we only choose robust and well-made PCs made by known-good manufacturers.

Does it make sense to always "Disable TCP Checksum Offload" on the NICs of a PC I could buy today? Or could I strike the above work instruction from the work sheet without having to fear outages on the customer's site?

Improve this question
4
  • While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
    – Ricky
    Jan 13, 2019 at 21:15
  • Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
    – Criggie
    Jan 14, 2019 at 0:51
  • 1
    Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
    – Simon Richter
    Jan 14, 2019 at 6:38
  • 1
    @Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
    – doppelfish
    Jan 14, 2019 at 19:54

3 Answers 3

Reset to default
2

Checksum offload is generally quite reliable. The last NIC I knew of that had a bug around this was a 100 Mbps Sun hme interface, which had a problem with UDP checksum offloads for IPv6 only. That was a long time ago.

Other TCP offloads, including full stack offload, and even segmentation offload (LSO, LRO) are riskier, and some caution there may be advised. I specifically dislike the attempts by some vendors to offload the entire TCP stack.

Improve this answer
1
  • Finally, an answer after 4½ years. Thank you!
    – doppelfish
    May 27 at 12:01
9

Hardware offloading features may have bugs but they are generally beneficial. I only deactivate them on certain NICs or vendors which do have problems.

However, on a workstation/PC the network load is usually low to very low - there's little benefit gained from offloading but there's still a risk of buggy hardware/drivers. That probably drove the work sheet's author to deactivate it in any case.

In servers, there is a lot more network traffic and other load, so there's more potential gain from offloading. Also, server (NIC) drivers are often better tested and potentially more stable.

The choice is still yours. ;-)

Improve this answer
4
  • Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
    – slebetman
    Jan 14, 2019 at 0:14
  • 1
    You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
    – james
    Jan 14, 2019 at 1:36
  • @james Excellent point - for capturing you should deactivate all offloading.
    – Zac67 ♦
    Jan 14, 2019 at 7:18
  • @james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
    – Marc 'netztier' Luethi
    Jan 15, 2019 at 17:43
3

I've just spent about 2 days debugging and figuring how to workaround a problem that seems to have come down to buggy TCP offloading with linux and Intel ethernet drivers/chipsets in Intel NUCs. Simple google searches reveal 1000s of reports just in this one driver (e1000e) going back over 10 years, many of which appear to be unfixed but can be worked around by disabling offloading one feature or another to the NIC. (Of course, some of these are hardware issues like broken cables or bad switches, but many people have ruled that out, there's definitely a large number of real problems in there - and broken cables/bad switches wouldn't be fixed by disabling offload.)

The manifestation of the problem was simply that maybe about once a day, the network card would pause for 30 seconds or so, and some (but not all) ongoing TCP sessions would be aborted due to corrupt packets. That's in the "really annoying, but hardly worth the bother of the user calling the helpdesk, and very low chance of anyone ever investigating and figuring out the cause" category in many large companies I've experienced.

So the answer is modern day NICs still suck, and I'd previously viewed Intel as 'known good' ethernet NIC vendor...

It honestly leaves me greatly puzzled - why is Intel not fixing these problems, and why does even bleeding edge linux (which I tried and didn't fix the problem) default to enabling checksum offload on this driver/chipset when it's known to be the source of many problems?

The benefit of checksum offload on modern processors on gigabit ethernet connections is minimal.

So overall I'd definitely side with disabling offload by default. The benefits are at best minimal in the majority of non-server situations, the downsides pretty bad (imagine 1,000 desktop users all losing 30 seconds a day - even taking the low end figure of a minimum wage worker, ignoring opportunity cost and assuming they can immediately resume exactly back where they were at the end of 30 seconds you're looking at wasted productivity 100 USD a day or about 25K USD a year lost - in reality much higher as this is a most optimistic figure.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.