Date: Wed, 4 Nov 2020 10:30:17 +0900 From: YongHyeon PYUN <pyunyh@gmail.com> To: Lowell Gilbert <Lowell@Be-Well.Ilk.Org> Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201104013017.GA48398@michelle> In-Reply-To: <44zh3ybd0s.fsf@Be-Well.Ilk.Org> 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> <44zh3ybd0s.fsf@Be-Well.Ilk.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 03, 2020 at 11:50:27AM -0500, Lowell Gilbert wrote: > 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 some > >> .. ahem, creative hardware behaviour: > >> > >> /* 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. > >> */ > >> > >> It’s not impossible that there’s some more issues like that in the hardware, > >> or even that there are different chip revisions out there. > >> > >> That also matches up with `ifconfig ue0 -rxcsum` fixing things. > >> > > > > 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). > > > > <---------------------------- 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. > > 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. I see. Publicly available data sheet was too much sanitized such that it's useless to implement checksum offloading. Given that you have access to data sheet, could you describe exact RX format of H/W? FreeBSD's USB stack requires copy operation for received frames so driver does not need any padding in RX path and ethernet frame alignment in mbuf can be adjusted in the copy operation. Since FCS bytes have no use in upper stack at this moment, it would be even better to strip FCS if there is way to do that in H/W. For TX checksum offloading support, we need more information on H/W's TX handling(TX_CTRL_0 and TX_CTRL_1) too. I guess it needs special magic sequence of programming(i.e. existence of SMSC_TX_CTRL_0_FIRST_SEG and SMSC_TX_CTRL_0_LAST_SEG) but it could be greatly simplified to program the H/W for TX checksum offloading since driver also have to copy entire mbuf chain to USB stack(i.e single big TX segment for the H/W).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201104013017.GA48398>