From owner-svn-src-user@FreeBSD.ORG Mon Nov 19 19:06:06 2012 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05CE55C7 for ; Mon, 19 Nov 2012 19:06:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 626048FC14 for ; Mon, 19 Nov 2012 19:06:04 +0000 (UTC) Received: (qmail 80820 invoked from network); 19 Nov 2012 20:39:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Nov 2012 20:39:08 -0000 Message-ID: <50AA831A.5000808@freebsd.org> Date: Mon, 19 Nov 2012 20:06:02 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: svn commit: r243291 - in user/andre/tcp_workqueue/sys: net netinet netinet6 netipsec netpfil/ipfw netpfil/pf References: <201211191804.qAJI4IXX014601@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 19:06:06 -0000 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