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

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

Στις Κυρ, 10 Μαρ, 2019 at 1:16 ΠΜ, ο/η Peter Geis 
<pgwipeout@gmail.com> έγραψε:
> 
> 
> On 3/9/2019 6:05 PM, Leonidas P. Papadakos wrote:
>> 
>> 
>> Στις Σαβ, 9 Μαρ, 2019 at 4:21 ΜΜ, ο/η Peter Geis 
>> <pgwipeout@gmail.com> \x7fέγραψε:
>>> 
>>> 
>>> 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 
>>>>>>> \x7f\x7f\x7f\x7f\x7f\x7frk3328-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 
>>>>>>> \x7f\x7f\x7f\x7f\x7f\x7fgetting
>>>>>>> 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 
>>>>>>> \x7f\x7f\x7f\x7f\x7f\x7f&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 
>>>>> \x7f\x7f\x7f\x7f0x20<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 \x7f\x7foffload in userspace instead.
>>> With threshold DMA I was having serious performance issues, but it 
>>> was \x7f\x7fbetter 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 
>> \x7ftx/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 
>> \x7fhappens
>> 
>> 3) the force-thresh-dma-mode patch with this one:
>>    No shs lag, and as before, the tx activity seems to hit less? 
>> (Maybe \x7fplacebo) but the link reset does happen regularly.
>> 
>> As far as I understand ayufan's offload patch removes the need for 
>> the \x7fforce-thresh-dma-mode flag.
>> I'll try ayufan's patch (adding the option to the rk3328-roc-cc as 
>> well) \x7ftogether 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?



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip