Problem with checksum offloading on RPi3 (PF + Jails involved)

[Lowell Gilbert]

YongHyeon PYUN <pyunyh at 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. 

----------