Message-ID: <a3c320fb-ede7-b525-5a39-96b62147b923@gmx.de>
Date:   Wed, 6 Mar 2019 12:35:49 +0100
From:   Simon Huelck <simonmail@....de>
To:     Jose Abreu <jose.abreu@...opsys.com>,
        Sebastian Gottschall <s.gottschall@...media-net.de>,
        Jerome Brunet <jbrunet@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     linux-amlogic@...ts.infradead.org, Gpeppe.cavallaro@...com,
        alexandre.torgue@...com,
        Emiliano Ingrassia <ingrassia@...genesys.com>,
        netdev@...r.kernel.org
Subject: Re: stmmac / meson8b-dwmac

Hi,

i sorted out some more things:

- i did not activate tcp window scaling , with this , iperf3 is reaching
930MBits now, this was related to my firewall and therefore my uplink.

so the remaining topic is ( and im currently testing with next-20190306 )

TX is starving RX and the total bandwith seem to be limited to 930MBits
instead of something like 930MBits * 2 for duplex.

@Jose, do you have some hints on that ? i saw that you introduced
patches for that , but somehow RX/TX are not equally sharing the NAPI
budget. But i wonder why the TX queue and RX queue collide at all,
shouldnt they be indipendent ?

regards,
Simon
> Hi guys,
>
>
> 1. i discovered something strange. when i never configure my external
> VLAN interface UP ( firewall doesnt start, traffic shaper CAKE doesnt
> start), my non duplex iperf bandwidth increases from 600MBits to 930.
>
> 2.  duplex isnt working, TX is totally starving RX, the total bandwidth
> is 900MBits, whats going on there ?
>
> 3. i had a MTU issue ( was set to 1500, but due to VLANs etc 1450 would
> be better ) but this didnt change performance
> 4. even when i up eth0.4, then i down eth0.4, then flush iptables and
> shaper were never added, i drop to 600MBits ....
>
> questions:
> - why is duplex still not working even so the kernel says so ?
> - why is TX totally starving RX, even so duplex is "on"
> - when i flush all my iptable rules, and the traffic shaper, still im
> bond to 600MBits ... very strange, someone got an idea ? upping eth0.4
> is cutting the performance, even when other VLAN IFs like eth0.3,
> eth0.2, eth0.5 are up and bridged ( eth0.4 isnt bridged somewhere )
>
>
>
> my setup:
>
> br-dmz          8000.7ef0fd9b157f       no              eth0.2
> br-guest                8000.001f1fbbbd60       no              wlan0
> br-iot          8000.7ef0fd9b157f       no              eth0.5
> br-lan          8000.001f1fbbbd61       no              eth0.3
>                                                         wlan0_1
>                                                         wlan2
>
> eth0.4 is my uplink
>
> all the bridges are internally , eth0.4 is externally
>
>
> C:\Users\Simon\Downloads\iperf3.6_64bit\iperf3.6_64bit>iperf3.exe -c
> 10.10.11.1 -i1
> warning: Ignoring nonsense TCP MSS 0
> Connecting to host 10.10.11.1, port 5201
> [  5] local 10.10.11.100 port 52173 connected to 10.10.11.1 port 5201
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec   384 KBytes  3.14 Mbits/sec
> [  5]   1.00-2.00   sec   384 KBytes  3.15 Mbits/sec
> [  5]   2.00-3.00   sec  1.12 MBytes  9.44 Mbits/sec
> [  5]   3.00-4.00   sec  2.00 MBytes  16.8 Mbits/sec
> [  5]   4.00-5.00   sec  2.38 MBytes  19.9 Mbits/sec
> [  5]   5.00-6.00   sec  3.12 MBytes  26.2 Mbits/sec
> [  5]   6.00-7.00   sec  4.75 MBytes  39.8 Mbits/sec
> [  5]   7.00-8.00   sec  68.4 MBytes   574 Mbits/sec
> [  5]   8.00-9.00   sec   104 MBytes   875 Mbits/sec
> [  5]   9.00-10.00  sec   105 MBytes   881 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-10.00  sec   292 MBytes   245 Mbits/sec                  sender
> [  5]   0.00-10.04  sec   292 MBytes   244 Mbits/sec                 
> receiver
>
> iperf Done.
>
>
> root@...oidc2:~# iperf3 -c 10.10.11.100 -i1
> Connecting to host 10.10.11.100, port 5201
> [  5] local 10.10.11.1 port 60022 connected to 10.10.11.100 port 5201
> [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
> [  5]   0.00-1.00   sec   112 MBytes   941 Mbits/sec    0    417 KBytes
> [  5]   1.00-2.00   sec   113 MBytes   945 Mbits/sec    0    487 KBytes
> [  5]   2.00-3.00   sec   112 MBytes   940 Mbits/sec    0    487 KBytes
> [  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    512 KBytes
> [  5]   4.00-5.01   sec   109 MBytes   907 Mbits/sec    0    543 KBytes
> [  5]   5.01-6.01   sec   109 MBytes   911 Mbits/sec    0    543 KBytes
> [  5]   6.01-7.01   sec   108 MBytes   902 Mbits/sec    0    543 KBytes
> [  5]   7.01-8.01   sec   108 MBytes   905 Mbits/sec    0    543 KBytes
> [  5]   8.01-9.00   sec   106 MBytes   895 Mbits/sec    0    543 KBytes
> [  5]   9.00-10.00  sec   106 MBytes   891 Mbits/sec    0    543 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Retr
> [  5]   0.00-10.00  sec  1.07 GBytes   918 Mbits/sec    0             sender
> [  5]   0.00-10.04  sec  1.07 GBytes   915 Mbits/sec                 
> receiver
>
> --
>
>
> Mar  5 09:46:03 localhost kernel: [  105.534204] meson8b-dwmac
> c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>
> iperf Done.
> root@...oidc2:~#
>
>
>
>
> regards,
> Simon
>
> Am 01.03.2019 um 10:23 schrieb Jose Abreu:
>> Hi Simon,
>>
>> On 2/27/2019 7:02 PM, Simon Huelck wrote:
>>> Hi,
>>>
>>>
>>> the thing is , that im not a stmmac developer. Yes , maybe i can bissect
>>> it and yes you are lucky since im a C-developer since a long time for
>>> embedded systems.
>>>
>>> The problem is that i dont understand the structure of stmmac and im not
>>> aware of any documentation about the driver structure nor the underlying
>>> ethernet hardware ( even though im used to ethernet hardware in embedded
>>> environment ). So how shall i recognize the relevant change between
>>> 4.14.29 and 5.0rc8 ?
>>>
>>>
>>> Is it in the DTS/DTB, wrong hardware description ? Is it in the code ?
>>> how is the duplex hardware working on this piece ?
>>>
>>> I can try to support you the best i can, but i have little chances to
>>> analyze it myself. At which measurements / counters is it possible to
>>> see that duplex is fully working ?  Why did even the non-duplex
>>> bandwidth regress from 900MBits to 650 ? Why is that 650 MBits dividing
>>> up to TX and RX in summary when doing duplex ? Why is TX not starving in
>>> duplex but RX ?
>>>
>>> From my point of view should be the following things given:
>>> - the non duplex bandwidth should be somewhere around 900MBits , the HW
>>> is capable of that
>>> - TX should not influence RX or vice versa in duplex
>>> - the duplex bandwidth should be 900MBits in both directions ( maybe a
>>> bit asymetric when buffers in both dirs are not same )
>>>
>>> I guess we need some profiling on stmmac and ( at least i need ) more
>>> knowledge of the hardware and stmmac itself. Can someone point me to the
>>> driver documentation, describing the functions in the code and the
>>> structure ? How can i profile stmmac ( usually im using hardware / JTAG
>>> debuggers at work, but here @home i got nothing like that )
>>>
>>> So how do we continue ?
>> When I said bissect I was meaning GIT Bissect [1]. You shouldn't
>> need any development background for this. You just have to start
>> bissect, compile, test and check if commit is good or not.
>>
>> I'm not very familiar with this feature but I think you can
>> bissect pretty fast if you say you just want stmmac commits,
>> check ("Cutting down bisection by giving more parameters to
>> bisect start") on previous link ... In your case it would be
>> stmmac changes, dts, and phy.
>>
>> [1] https://git-scm.com/docs/git-bisect
>>
>> Thanks,
>> Jose Miguel Abreu
>

Powered by blists - more mailing lists