Date: Sun, 8 Feb 2009 12:56:21 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Jeremy <peter@vk2pj.dyndns.org> Cc: freebsd-stable@freebsd.org Subject: Re: impossible packet length ... Message-ID: <alpine.BSF.2.00.0902081252300.1129@fledge.watson.org> In-Reply-To: <20090208104253.GB31876@test71.vk2pj.dyndns.org> References: <E1LW5Ht-0000VH-D8@kabab.cs.huji.ac.il> <20090208091656.GA31876@test71.vk2pj.dyndns.org> <E1LW60v-0000zC-B2@kabab.cs.huji.ac.il> <20090208104253.GB31876@test71.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Feb 2009, Peter Jeremy wrote: > On 2009-Feb-08 11:31:45 +0200, Danny Braniss <danny@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0902081252300.1129>