From owner-freebsd-hackers@freebsd.org Tue Nov 3 08:15:58 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 894BD45018F; Tue, 3 Nov 2020 08:15:58 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CQMzy39W1z4lFR; Tue, 3 Nov 2020 08:15:58 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 2437336CF2; Tue, 3 Nov 2020 08:15:58 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id C46484D176; Tue, 3 Nov 2020 09:15:52 +0100 (CET) From: "Kristof Provost" To: "YongHyeon PYUN" Cc: "John-Mark Gurney" , "Carsten =?utf-8?q?B=C3=A4cker?=" , freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Date: Tue, 03 Nov 2020 09:15:51 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <20201103045215.GA2524@michelle> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 08:15:58 -0000 On 3 Nov 2020, at 5:52, YongHyeon PYUN wrote: > > I'm not sure where the root cause is but it seems smsc(4) needs > improvement in RX checksum handling. That=E2=80=99s my thinking as well, yes. I=E2=80=99m not quite sure how t= hough, = because the received packet should contain full and correct checksums = regardless of the hardware=E2=80=99s checksum handling, so pf shouldn=E2=80= =99t have = any issues updating checksums. Ah, except that the driver also copies the checksum into the mbuf=E2=80=99= s = csum_data field, and if that checksum is wrong we would indeed see pf = update an incorrect checksum, and we=E2=80=99d get forwarded packets with= bad = checksums. That also matches with the observation that the problem goes = away when rx checksum offload is disabled. > Quick reading RX handler > indicates RX checksum offloading does not work when: > o IP datagram has IP options field > o TCP/UDP packet was fragmented > o UDP datagrams with 0 checksum value > See fxp(4), gem(4) and hme(4) for implementation. > > It looks like smsc(4) uses the following RX format but I don't > know actual RX format of H/W(no access to datasheet). > Happily Microchip do publish the datasheet: = http://ww1.microchip.com/downloads/en//softwarelibrary/man-lan95xx-dat/la= n9512_lan9512i%20databook%20rev.%201.2%20(03-01-12).pdf It may indeed be the case that this happens when the IP (or TCP) header = has options, but without a clear capture (or ideally, access to a setup = to reproduce the problem) it=E2=80=99s hard to tell. The datasheet has the great benefit of existing and being published, but = it does lack a bit of detail when it comes to the RX checksum offload = engine. > <---------------------------- actlen = > --------------------------------------------------> > <------------- pktlen ------------------------> > rxhdr(4 bytes) | padding (2 bytes) | RX frame | FCS(4 bytes) | partial = > checksum(2 bytes) > > If the format above is correct smsc(4) needs more strict RX length > validation(USB transfer size vs actual packet length). This > indicates smsc(4) does not have to copy FCS bytes. > Also given that H/W always appends FCS, it's also suspicious H/W > does not correctly compute RX checksum for frames less than or > equal to 64 bytes. > > I don't have H/W and some spare time to fix this though. :-( > Sadly I don=E2=80=99t have this hardware either. Best regards, Kristof