On Sun, 8 Feb 2009, Peter Jeremy wrote:
On 2009-Feb-08 11:31:45 +0200, Danny Braniss <da...@cs.huji.ac.il> wrote:
Q: with rxcsum on, and a bad checksum packet is received, is it
dropped by the NIC? if not, then it somewhat explains the behaviour
If checksum offloading is working correctly then a bad packet should be
dropped by the NIC. If checksum offloading isn't working correctly then you
can wind up in the situation where both the NIC and the driver think the
other party has verified the checksum. It's also possible that you may be
running into corruption during DMA transfer from the NIC to RAM. ISTR there
have been some issues reported recently with checksum offloading on some
NICs - though I don't have details to hand - you might like to search the
lists.
changing the nic is tough, but if needed will be done.
If disabling checksum offloading fixes the problem and the additional CPU
load is acceptable (at least until you find a real fix) then there's no need
to change NICs.
Actually, my understanding was that packets with bad checksums are delivered
to software, and flag the descriptor ring header for each packet tells us
whether the checksum was (a) checked and (b) validated by the hardware. We
then propagate these to mbuf flags so that higher stack layers know whether or
not to calculate the checksum themselves. Regardless of the specifics,
though, packets with checked but bad checksums shouldn't make it to the socket
layer where they would be visible to NFS. If the NIC is marking apparently
bad packets as good, there are a number of possible sources -- be it bad
checksum handling in the card, corruption between the card and higher levels
of the stack (a DMA problem, as you point out, would have this symptom).
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
