Date: Mon, 19 Nov 2012 20:06:02 +0100 From: Andre Oppermann <andre@freebsd.org> To: Michael Tuexen <tuexen@fh-muenster.de> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r243291 - in user/andre/tcp_workqueue/sys: net netinet netinet6 netipsec netpfil/ipfw netpfil/pf Message-ID: <50AA831A.5000808@freebsd.org> In-Reply-To: <C0E2921E-E2DC-4D12-B163-AD7A0269894C@fh-muenster.de> References: <201211191804.qAJI4IXX014601@svn.freebsd.org> <C0E2921E-E2DC-4D12-B163-AD7A0269894C@fh-muenster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19.11.2012 19:57, Michael Tuexen wrote: > On Nov 19, 2012, at 7:04 PM, Andre Oppermann wrote: > >> Author: andre >> Date: Mon Nov 19 18:04:17 2012 >> New Revision: 243291 >> URL: http://svnweb.freebsd.org/changeset/base/243291 >> >> Log: >> Convert IP, IPv6, UDP, TCP and SCTP to the new checksum offloading >> semantics on the inbound and outbound path. >> >> In short for inbound there are two levels the offloading NIC can >> set: >> >> CSUM_L3_CALC for an IP layer 3 checksum calculated by the NIC; >> CSUM_L3_VALID set when the calculated checksum matches the one >> in the packet; >> CSUM_L4_CALC for an UDP/TCP/SCTP layer 4 checksum calculated by >> the NIC; >> CSUM_L4_VALID set when the calculated checksum matche the one >> in the packet. >> >> From this follows that a packet failed checksum verification when >> only *_CALC is set but not *_VALID. The NIC is expected to deliver >> a failed packet up the stack anyways for capture by BPF and to >> record protocol specific checksum mismatch statistics. >> >> The old approach with CSUM_DATA_VALID and CSUM_PSEUDO_HDR could not >> signal a failed packet. A failed packet was delivered into the stack >> and the protocol had to recalculate the checksum for verification >> every time to detect that as the absence of CSUM_DATA_VALID didn't >> signal that the packet was broken. It was only saying that the >> checksum wasn't calculated by the NIC, which actually wasn't the case. >> >> Drag the other stack infrastructure, including packet filters, along >> as well. > I looked at the code for SCTP. If the NIC reports that it computed the > checksum and the checksum is not reported as valid, you are dropping the > packet. The problem with this code is, that at least some NICs report > for small SCTP packets that the checksum is wrong. To deal with this, > I did the checksum verification is software in case the hardware reported > a bad checksum. Are you planning to deal with this in the specific drivers? Yes, in that case the definition is that the driver must not set CSUM_L4_CALC and CSUM_L4_VALID so the protocol can calculated the checksum itself. If it is known that, for example, packets shorter than 128 bytes are not correctly calculated by hardware the driver must check for that when it sets the checksum flags. Do you have a list of NICs that are broken with SCTP/CRC32c in particular cases? It may be helpful to add an INVARIANTS case where the checksum is always recomputed by the protocol as well and compared with the outcome of the hardware calculation. That way we cancatch misbehaving NICs early on. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50AA831A.5000808>