Date: Mon, 19 Nov 2012 21:23:53 +0100 From: Michael Tuexen <tuexen@fh-muenster.de> To: Andre Oppermann <andre@FreeBSD.org> 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: <4973333F-FDA4-412E-91F2-64639BDB04A6@fh-muenster.de> In-Reply-To: <50AA831A.5000808@freebsd.org> References: <201211191804.qAJI4IXX014601@svn.freebsd.org> <C0E2921E-E2DC-4D12-B163-AD7A0269894C@fh-muenster.de> <50AA831A.5000808@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 19, 2012, at 8:06 PM, Andre Oppermann wrote: > On 19.11.2012 19:57, Michael Tuexen wrote: >> On Nov 19, 2012, at 7:04 PM, Andre Oppermann wrote: >>=20 >>> Author: andre >>> Date: Mon Nov 19 18:04:17 2012 >>> New Revision: 243291 >>> URL: http://svnweb.freebsd.org/changeset/base/243291 >>>=20 >>> Log: >>> Convert IP, IPv6, UDP, TCP and SCTP to the new checksum offloading >>> semantics on the inbound and outbound path. >>>=20 >>> In short for inbound there are two levels the offloading NIC can >>> set: >>>=20 >>> 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. >>>=20 >>> =46rom 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. >>>=20 >>> 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. >>>=20 >>> 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? >=20 > 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. >=20 > Do you have a list of NICs that are broken with SCTP/CRC32c in > particular cases? If I remember correctly, igb with packets up to 64 bytes (such there is final ethernet padding). >=20 > 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. Not sure we need this. In case the driver reports the checksum as bad and the transport layer will drop the packet, the connection will = eventually break. We also have counters... So it should show up during testing. Best regards Michael >=20 > --=20 > Andre >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4973333F-FDA4-412E-91F2-64639BDB04A6>