From: Simon Huelck <simonmail@gmx.de>
To: Jose Abreu <jose.abreu@synopsys.com>,
Sebastian Gottschall <s.gottschall@newmedia-net.de>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: linux-amlogic@lists.infradead.org, netdev@vger.kernel.org,
alexandre.torgue@st.com,
Emiliano Ingrassia <ingrassia@epigenesys.com>,
Gpeppe.cavallaro@st.com
Subject: Re: stmmac / meson8b-dwmac
Date: Wed, 6 Mar 2019 12:35:49 +0100 [thread overview]
Message-ID: <a3c320fb-ede7-b525-5a39-96b62147b923@gmx.de> (raw)
In-Reply-To: <fa098953-225c-17fb-9cc1-b83e5ae1662c@gmx.de>
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@odroidc2:~# 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@odroidc2:~#
>
>
>
>
> 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
>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-03-06 11:36 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a38e643c-ed9f-c306-cc95-84f70ebc1f10@gmx.de>
[not found] ` <CAFBinCDebPOsmrhSXecx48nGWHh7g_OGPbr1Y0M+n_v9Ht91ew@mail.gmail.com>
2019-01-17 21:23 ` stmmac / meson8b-dwmac Simon Huelck
2019-02-04 14:34 ` Martin Blumenstingl
2019-02-06 10:36 ` Emiliano Ingrassia
2019-02-06 18:04 ` Simon Huelck
2019-02-06 21:21 ` Simon Huelck
2019-02-07 19:30 ` Simon Huelck
2019-02-09 1:09 ` Martin Blumenstingl
2019-02-11 13:44 ` Jose Abreu
2019-02-14 7:21 ` Simon Huelck
2019-02-17 14:48 ` Martin Blumenstingl
2019-02-17 19:13 ` Simon Huelck
2019-02-18 8:42 ` Jose Abreu
2019-02-18 8:45 ` Jose Abreu
2019-02-18 12:33 ` Simon Huelck
2019-02-18 12:41 ` Jose Abreu
2019-02-18 13:02 ` Jose Abreu
2019-02-18 15:29 ` Simon Huelck
2019-02-18 15:31 ` Jose Abreu
2019-02-18 15:53 ` Simon Huelck
2019-02-18 16:26 ` Jose Abreu
2019-02-18 16:40 ` Simon Huelck
2019-02-18 16:43 ` Jose Abreu
2019-02-18 16:51 ` Simon Huelck
2019-02-18 17:05 ` Jose Abreu
2019-02-18 18:05 ` Simon Huelck
2019-02-19 8:47 ` Jose Abreu
2019-02-19 19:41 ` Simon Huelck
2019-02-21 14:21 ` Jerome Brunet
2019-02-21 17:27 ` Simon Huelck
2019-02-21 17:46 ` Jerome Brunet
2019-02-21 19:34 ` Simon Huelck
2019-02-22 17:21 ` Anand Moon
2019-02-24 15:00 ` Simon Huelck
2019-02-24 15:02 ` Simon Huelck
2019-02-24 19:42 ` Sebastian Gottschall
2019-02-24 20:34 ` Simon Huelck
2019-02-27 11:09 ` Jose Abreu
2019-02-27 19:02 ` Simon Huelck
2019-03-01 9:23 ` Jose Abreu
2019-03-05 9:55 ` Simon Huelck
2019-03-06 11:35 ` Simon Huelck [this message]
2019-03-06 11:45 ` Simon Huelck
2019-05-11 14:53 ` Simon Huelck
2019-05-13 9:07 ` Jose Abreu
2019-05-22 12:48 ` Simon Huelck
2019-05-22 14:02 ` Neil Armstrong
2019-02-27 21:03 ` Simon Huelck
2019-02-18 17:05 ` Simon Huelck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3c320fb-ede7-b525-5a39-96b62147b923@gmx.de \
--to=simonmail@gmx.de \
--cc=Gpeppe.cavallaro@st.com \
--cc=alexandre.torgue@st.com \
--cc=ingrassia@epigenesys.com \
--cc=jbrunet@baylibre.com \
--cc=jose.abreu@synopsys.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=netdev@vger.kernel.org \
--cc=s.gottschall@newmedia-net.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).