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

[YongHyeon PYUN]

On Tue, Nov 03, 2020 at 11:31:03PM -0500, Lowell Gilbert wrote:
> YongHyeon PYUN <pyunyh at gmail.com> writes:
> 
> > On Tue, Nov 03, 2020 at 11:50:27AM -0500, Lowell Gilbert wrote:

[...]

> 
> Sorry, but I only have the public data sheet currently.
> http://ww1.microchip.com/downloads/en/devicedoc/ds_lan89530_60001347a.pdf
> 

Oh, thanks a lot.

> > 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.
> 
> As I read this, the FCS is stripped if the padding is, but if you do
> that, you have to disable the IP RX checksum offloading.
> That's the note at the bottom of page 71.
> 

Yup, found it.

> I think the padding after the status word is strictly to word-align the
> frame start, so you seem to have what you're looking for.
> 
> The pre-frame padding is set by a Hardware Configuration Register.
> 

Yes it seems, I disabled it in my patch as it is not required.

> > 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).
> 
> The scatter-gather handling is driven from the first and last segment
> flags, but the checksum addition *seems* to just happen by magic if the
> checksum enable flag is also set. According to this data sheet, the
> checksum enable flag has no effect except on the first segment, but
> setting it the same way in every segment would be prudent.
> 
> I have no idea if all of the chips under this driver use the same
> command word formats, but they probably do.
> 

Linux driver seems to have no special handling on other revisions
so I think you're right.  The real issue in TX checksum offloading
is workaround for H/W limitation(bug?). It looks like H/W does not
correctly compute checksum when checksum insertion offset is in the
last 4 bytes of the TX packet which would be the case for pure-TCP
ACK segments. For UDP case, we probably can't enable checksum
offloading since the H/W is not smart enough to change UDP checksum
value to 0xffff.

> My experience is several years ago, and I have no hardware to try things
> out on...

Me too. :-(