Date: Tue, 03 Nov 2020 11:53:54 -0500 From: Lowell Gilbert <freebsd-lists@Be-Well.Ilk.Org> To: YongHyeon PYUN <pyunyh@gmail.com> Cc: Kristof Provost <kp@FreeBSD.org>, John-Mark Gurney <jmg@funkthat.com>, Carsten =?iso-8859-1?Q?B=E4cker?= <carbaecker@gmx.de>, freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <44v9embcv1.fsf@Be-Well.Ilk.Org> In-Reply-To: <20201103045215.GA2524@michelle> (YongHyeon PYUN's message of "Tue, 3 Nov 2020 13:52:15 %2B0900") 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
YongHyeon PYUN <pyunyh@gmail.com> writes: > On Thu, Oct 29, 2020 at 10:39:39PM +0100, Kristof Provost wrote: > > [...] > >> It does seem to do RX offload, and the comments in the driver suggest so= me >> .. ahem, creative hardware behaviour: >>=20 >> /* The checksum appears to be simplistically calculated >> * over the udp/tcp header and data up to the end of the >> * eth frame. Which means if the eth frame is padded >> * the csum calculation is incorrectly performed over >> * the padding bytes as well. Therefore to be safe we >> * ignore the H/W csum on frames less than or equal to >> * 64 bytes. >> * >> * Ignore H/W csum for non-IPv4 packets. >> */ >>=20 >> It=92s not impossible that there=92s some more issues like that in the h= ardware, >> or even that there are different chip revisions out there. >>=20 >> That also matches up with `ifconfig ue0 -rxcsum` fixing things. >>=20 > > I'm not sure where the root cause is but it seems smsc(4) needs > improvement in RX checksum handling. 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).=20=20=20=20=20=20= =20=20=20=20=20=20=20 > > <---------------------------- actlen ------------------------------------= --------------> > <------------- pktlen ------------------------> > rxhdr(4 bytes) | padding (2 bytes) | RX frame | FCS(4 bytes) | partial ch= ecksum(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. For the 89530 at least, the data sheet states that checksum offload and padding stripping are mutually exclusive. I would assume that enabling both of them will produce incorrect results. I would *not* assume that all chips covered by this driver behave the same way, although it's likely.=20 ----------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44v9embcv1.fsf>