Hi Peter, > On 13 Dec 2019, at 12:48, Peter Geis <pgwipeout@xxxxxxxxx> wrote: > > On Thu, Dec 12, 2019 at 8:21 AM Peter Geis <pgwipeout@xxxxxxxxx> wrote: >> >> Good Morning, >> >> So I've continued work on fixing the rk3328/rk3399 gmac mtu tx coe offload bug. >> I've found two fixes that maintain full performance and work consistently. >> >> First, is ayufan's tx coe patch [0], which takes the bugged_jumbo >> concept introduced in [1] and applies it to 1498 and above, vice 1500 >> and above. >> >> The only downside is this disables tx coe for full size packets, which >> has a negligible performance impact in my testing. >> >> The other option I've found that reliably works is bringing the mtu >> down to 1498. >> This allows tx coe to remain enabled, but with the downside of total >> loss of jumbo frames. >> The reduction in size has a negligible performance impact in my testing. > > Shortly after sending this I discovered that setting the mtu lower is > not sufficient in some corner cases. > I managed to make offload break even at a 1496 mtu by `apt install > kubuntu-desktop` over ssh on a gigabit internet connection. > > After porting ayufan's patch the issue went away. > So unless we can fix this by axi tuning, his patch seems to be the > most viable option. > Have you tried suggestions from Jose in https://lkml.org/lkml/2019/4/1/1382? I've added "snps,no-pbl-x8;" and "snps,txpbl = <0x20>;" to the gmac in the DT, on rk3399-rockpro64. This seems to fix the slow performance on IPv6 specifically that I was seeing. I haven't done exhaustive testing beyond a few runs of iperf3, which seem to show OK performance for a gigabit link on home networking hardware. 874 Mbits/sec for IPv4, 856 Mbits/sec for IPv6, with MTU 1500. >> >> >> I have also discovered that the rockchip implementation of the stmmac >> driver does not process flags such as max-frame-size. >> >> A third option, which I haven't explored because I don't know enough >> about how it works, is possibly tuning the axi settings, via the >> snps,axi-config and snps,mtl-tx-config handles. >> I don't know if this is feasible, but since tuning the dma settings >> affects the rk3328 I have hope. >> I do know that my current fix for the rk3328 does not provide full >> performance and does not work at all on the rk3399. >> >> Thoughts? >> >> [0] https://github.com/ayufan-rock64/linux-kernel/commit/8a41c672dd77e48b06c1b2dec3aa9db4bad30b49#diff-c897c0b53bd633240f4b12c4d29a5ff1 >> [1] https://github.com/torvalds/linux/commit/ebbb293f8b3021ae2009fcb7cb3b8a52fb5fd06a > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-rockchip _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
