[clip]
For the test I use iperf3 -s on my laptop (Gigabit Ethernet)
and on the renegade: iperf3 -c <laptop_ip> -t 30.
I tried using:
1) the force-thresh-dma-mode patch by itself with the changed
tx/rx_delay. (Maybe the default one is better? It needs testing nayway)
No ssh lag but I do get the Link reset on tx activity
2) just this patch by itself
the ssh lag hit me, but it does seem better. The link reset
still happens
3) the force-thresh-dma-mode patch with this one:
No shs lag, and as before, the tx activity seems to hit less?
(Maybe placebo) but the link reset does happen regularly.
As far as I understand ayufan's offload patch removes the need for
the force-thresh-dma-mode flag.
I'll try ayufan's patch (adding the option to the rk3328-roc-cc as
well) together with this patch.
Maybe it'll be better
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.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
