impossible packet length ...
rwatson at FreeBSD.org
Sun Feb 8 04:56:22 PST 2009
On Sun, 8 Feb 2009, Peter Jeremy wrote:
> On 2009-Feb-08 11:31:45 +0200, Danny Braniss <danny at 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
>> 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
University of Cambridge
More information about the freebsd-stable