> 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).
looking at the bce source, it's not clear (to me :-). If errors are detected in bce_rx_intr(), the packet gets dropped, which I would expect to be the treatment of an offloded chekcum error, but it seems that is not the case. danny _______________________________________________ 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"
