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

[Hans Petter Selasky]

On 2020-11-03 05:52, YongHyeon PYUN wrote:
> 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. :-(

I can review and test patches. Seems like there is need for a fix.

--HPS