Date: Tue, 03 Nov 2020 09:15:51 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: "YongHyeon PYUN" <pyunyh@gmail.com> Cc: "John-Mark Gurney" <jmg@funkthat.com>, "Carsten =?utf-8?q?B=C3=A4cker?=" <carbaecker@gmx.de>, freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <AA506DE6-28AC-4BD9-AF9E-5D35619F5ACA@FreeBSD.org> In-Reply-To: <20201103045215.GA2524@michelle> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <D8CE4762-4D94-47C7-A8D1-6C537766813B@FreeBSD.org> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA506DE6-28AC-4BD9-AF9E-5D35619F5ACA>