On 3/9/2019 6:05 PM, Leonidas P. Papadakos wrote:
Στις Σαβ, 9 Μαρ, 2019 at 4:21 ΜΜ, ο/η Peter Geis <pgwipeout@xxxxxxxxx>
έγραψε:
On 3/9/2019 9:16 AM, Heiko Stuebner wrote:
Am Samstag, 9. März 2019, 13:45:21 CET schrieb Peter Geis:
On 3/8/2019 10:26 PM, Leonidas P. Papadakos wrote:
So I discovered the cause of my TX issues, at least on my
rk3328-roc-cc.
The rk3328.dtsi is missing several rgmii tx pull strength values.
This is causing them to default to 0ma.
I've pushed them to 12ma, same as the other tx values, and I'm
getting
600 mbps tx, with no TX failures.
I am also going to test his adaptive patch once it's done building.
Thoughts?
diff --git a/arch/arm65/boot/dts/rockchip/rk3328-roc-cc.dts
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index c0519bc5884e..696627bf3331 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -280,6 +280,26 @@
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO
&pcfg_pull_none>;
};
};
+
+ gmac-1 {
+ rgmiim1_pins: rgmiim1-pins {
+ rockchip,pins =
+ /* mac_txclk */
+ <0 RK_PB0 1 &pcfg_pull_none_12ma>,
+ /* mac_txen */
+ <0 RK_PB4 1 &pcfg_pull_none_12ma>,
+ /* mac_clk */
+ <0 RK_PD0 1 &pcfg_pull_none_12ma>,
+ /* mac_txd1 */
+ <0 RK_PC0 1 &pcfg_pull_none_12ma>,
+ /* mac_txd0 */
+ <0 RK_PC1 1 &pcfg_pull_none_12ma>,
+ /* mac_txd3 */
+ <0 RK_PC7 1 &pcfg_pull_none_12ma>,
+ /* mac_txd2 */
+ <0 RK_PC6 1 &pcfg_pull_none_12ma>;
+ };
+ };
};
&sdmmc {
Good find! It seems like they're there in the dtsi, but configured as
none when it comes to ma. I'll test it
With Ayufan's patch offload patch and my pull patch, I now have the
following results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 1022 MBytes 857 Mbits/sec 885 sender
[ 5] 0.00-10.01 sec 1022 MBytes 856 Mbits/sec
receiver
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::e8b5:5eff:fe49:d353 prefixlen 64 scopeid
0x20<link>
ether ea:b5:5e:49:d3:53 txqueuelen 1000 (Ethernet)
RX packets 39822 bytes 2668618 (2.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1005649 bytes 1516698158 (1.5 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 29
Much better overall, still not perfect, but I think it might be worth
re-running the delay tests now.
also you could check if the thres-dma-flag is still necessary or can
be removed - might be interesting to know if fixing the drive strength
magically also fixes that issue.
Heiko
Part of my test was removing that flag.
I actually haven't run with it for a while, since I chose to disable
offload in userspace instead.
With threshold DMA I was having serious performance issues, but it was
better than networking being completely broken.
I'll write up a patch for the .dtsi and submit it today.
If we can contact ayufan about his patch, that would be great!
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.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
