Re: [PATCH v2] arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay

["Leonidas P. Papadakos" <papadakospan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

> > > We have several issues on the rk3328.
> > > 
> > > The first issue, which you describe as the ssh lag, is the
> > > tx-offload issue.
> > > Packets that are larger than the MTU and will be fragmented break if
> > > tx-offload is enabled.
> > > To fix this, you must somehow disable tx-offload.
> > > force-thresh-dma-mode disabled tx-offload, but had other side effects.
> > > Ayufan's patch disables tx-offload only if the packet is larger than
> > > 1498.
> > > You can also disable tx-offload from userspace with ethtool.
> > > 
> > > The second issue is the high rate of tx packets being corrupted,
> > > which my patch to set the tx pull values fixes.
> > > 
> > > The third issue is the tx and rx delays need to be tuned now that
> > > the tx packet corruption issue has been fixed.
> > > 
> > > I hope this clears things up a little for you.
> > 
> > Yup, that's what I have in my mind already. My previous comment wasn't
> > clear, I know.
> > I pieced it together after your dma-mode patch, because that one fixed
> > the ssh lag.
> > My previous email was just what I saw after those changes.
> > 
> > In my case the link reset still happens with your patch.
> > 
> > You're thinking that the combination of your patch, ayufan's
> > "conditional" patch and a specific tweak in the delays would work for
> > the network instability problem?
> > 
> 
> Correct, the link-reset tends to happen when the delays are at the edge of
> working.
> There is also the possibility that board level manufacturing tolerances are
> causing issues where the delay can change between boards.
> If this is the case, we will have to make an auto-tune function, probably
> based off the mmc version.

So, I tried just your patch with archlinuxARM linux 5.0
(meaning the tx/rx_delays are 0x25/0x11 respectively if I'm not mistaken)
and disabled tx offload through ethtool.

After 3 30-second iperf3 tests, no link resets! I get about the same speed you mentioned before,
800-something to 700-something lowest.

Seems like the delays that are already there in the dts are better than the ones I picked up from the Armbian dts.

It's worth noting that I've never noticed a link reset in my ~3 months of using the 4.4 Rockchip kernel
that Armbian packages using ayufan's linux-kernel repo. Maybe something there?

All in all, it does seem to be much better with your patch.