As part of the effort to putback a fix for 6587116 (which impacts
checksum offload on my recent hme for cases where the packet is too
small), the code reviewer (Bill Sommerfeld) asked about the difference
between the handling of TCP vs. UDP checksums. (Specifically what
happens when the checksum calculation results in a zero value.)
What has become clear is:
1) the stack interface hcksum_retrieve() does not differentiate between
TCP and UDP for partial checksums.
2) the "software" workaround for tiny packets in qfe (and that I mostly
borrowed for hme) is broken.
3) we do not know what the Sun hardware (hme, eri/gem, ce, nxge) do in
the situation... do they return +0, or -0 (0xffff)?
4) unless the hardware is examining the packet contents to learn if the
data is TCP or UDP, then it is *wrong* for either TCP or UDP.
So, I need answers from folks with access to knowledge about the
hardware (#4 above). Once we know which way the hardware behaves, we
can decide what to do about TCP and UDP checksum offload. Probbably,
what we need to do is turn off checksum offload for UDP, because I
*think* it is right for TCP.
I suspect that we will need to stop using TX checksum offload for one or
the other of TCP or UDP, at least for NICs that do partial checksum
offload. (Having, of course, a nasty performance impact on the other
side.)
The fix for 6587116 (which may impact PIT testing) is blocked until I
can figure out how to proceed. My code reviewer has denied me from
taking the same course of action used in qfe, as a result of this issue.
We need to figure this out.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
