Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Nov 2020 13:52:15 +0900
From:      YongHyeon PYUN <pyunyh@gmail.com>
To:        Kristof Provost <kp@FreeBSD.org>
Cc:        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:  <20201103045215.GA2524@michelle>
In-Reply-To: <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

I don't have H/W and some spare time to fix this though. :-(



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201103045215.GA2524>