From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D755DC43381 for ; Tue, 5 Mar 2019 09:56:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9BDC72082C for ; Tue, 5 Mar 2019 09:56:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727405AbfCEJ4b (ORCPT ); Tue, 5 Mar 2019 04:56:31 -0500 Received: from mout.gmx.net ([212.227.15.19]:56917 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbfCEJ4a (ORCPT ); Tue, 5 Mar 2019 04:56:30 -0500 Received: from [10.10.11.100] ([95.88.214.118]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MCcja-1grn8I2Ij4-009RnV; Tue, 05 Mar 2019 10:56:12 +0100 Subject: Re: stmmac / meson8b-dwmac To: Jose Abreu , Sebastian Gottschall , Jerome Brunet , Martin Blumenstingl Cc: linux-amlogic@lists.infradead.org, Gpeppe.cavallaro@st.com, alexandre.torgue@st.com, Emiliano Ingrassia , netdev@vger.kernel.org References: <065407cd-c13b-e74c-7798-508650c12caf@gmx.de> <227be4e9-b0cc-a011-2558-71a17567246f@synopsys.com> <45e73e8c-a0fb-6f8f-8dc6-3aa2103fdda3@gmx.de> <4493b245-de93-46cd-327b-8091a3babc3a@gmx.de> <244d7c74-e0ca-a9c7-f4b0-3de7bec4024b@gmx.de> <1426d8ed40be0927c135aff25dcf989a11326932.camel@baylibre.com> <9074d29b-4cc9-87b6-009f-48280a4692c0@gmx.de> <8ec64936-c8fa-1f0e-68bf-2ad1d6e8f5d9@gmx.de> <3a040370-e7e5-990e-81dc-8e9bb0ab7761@gmx.de> <12d1d6de-2905-46a8-6481-d6f20c8e9d85@gmx.de> <2c4d9726-6c2a-cd95-0493-323f5f09e14a@synopsys.com> From: Simon Huelck Openpgp: preference=signencrypt Autocrypt: addr=simonmail@gmx.de; prefer-encrypt=mutual; keydata= mQGiBD/bCNARBACE3URTBXZ/AA03NwRNtz03ewQn3uhvYSTjfqgplBtb3dfC4a79BXDRIWVX xPGH9Ewios1c8gMu3/RI2l3JzXoISfw5b0L/5igyPKV+sGuUA2FD27kYtPaaF/TqEWIv+Yxp 9DCjCX5IQSYyvCfcxcyEkY8eVWxnaAlV3zKRR8wn0wCglWIOtAugBcg1YXmoLpFZE8Ca0fkD /jG+n4U9DPfCgkbgjQ/dv2W2a0ZDHccA9N8AW/FTXGyXXO0e7ql9/kORJnp7jD7/Z9HCKpeS HajgxuX9Vhfx6bH1dAMfsg88+K8pOO9oulNX1+YffQyZWOfdbmnZDUzBt9HKR9Wgh8WoIyw9 TVluclzn6hYz+z9jbqHWMOsiCu8zA/0apHbW8vaIDT4+nNUxNdqU1TKa9kW47vNjwYYL0jZW TXNjDIRpqJVSugYVc/U847GoVoxyvtzre4TAbBV8h0BAOeMdxI5En67RGWzeNaMDJV1bwapj qdfj3e/X8rnGIfwz47rwztLNKoAIUlKrATwroiI7UNT+84G7H5qalu+Eu7QqU2ltb24gSHVl bGNrIDxzaW1vbi5odWVsY2tAZ29vZ2xlbWFpbC5jb20+iGIEExECACIFAlH7wL4CGyMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNSVvfBt05KlBQAn1JDO7e4H3N0WFJkZnxvObhk 2kiAAJwPdDd6T1TuGo4iDIENRhAX4AH2KrkBDQQ/2wjSEAQAj6JnDDQzIIYzPGsrHRvaq8vw n8VrZCbPRvkngGvtQIss5pH/MLeu9jLepDGO9WHByFSg4QJh8cINYwTLtX8Bu0naA6ZI46hn GyfxdRlxSU9dRqHpU3G0tymL1w3AER6aVSfdXQTmFgf61anKunbIIptkqzZurkjnxkwCE/RM RscABA0D/jhglpj8siSIAxs8XLVfKJrjzbYM9/wS0NfdSXBeQJiYtKrY0WMNsqjY50wDnLMg anORN/odT6mCwKI6xChzxEv/ta4+teZl92aitziSuqmtl+jm23DpOcUC7UBz2W1+TvnrhPR+ MKu8pPKAgsE8AI5uwCcNJx7V3bczYkIGaXybiEYEGBECAAYFAj/bCNIACgkQk1JW98G3Tko6 3wCfZBpZAUhUz/Rcp2rfg/YSKl4YLlEAoJN7e322OvHc2GQ9n1+tKLi6Og4c Message-ID: Date: Tue, 5 Mar 2019 10:55:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <2c4d9726-6c2a-cd95-0493-323f5f09e14a@synopsys.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:MDsMSUll5rqGDv7aSJuKB4Uuyip4nBQHXBcD2KjI/pBmLNxGZLi CTBa1h/V5mbqKXldHzVH5QAnc5HS0A7bbyUMsmJ3x+zyMlOGCWcbSBJxTmAP/UO2LrcmEvL ykir2NCsJ6Nm1q3nuPBJOw6XoMROW0Baf9h1p/Qt5lYoIX3Z9ZCts7KYsq0Bg5OeTTnLWbd LYNc8DxnDX5hAcelQvyXg== X-UI-Out-Filterresults: notjunk:1;V03:K0:NJF8FGQCldU=:X81E/BR4R2RU84OH5czCW3 kXqeNbs7+43pe5Sos9XYkyIM10XMWCW7bDDcaFqT4pmeGPOTZcCTvjEA/Sb0KVCbtAovWY2p9 a8ahZDD/EaWsX6gNBTy7A4QwK4r5oaQ3o9EzkW6yZ6NyQOOSsjcV/3lRowil+uMkWMvx/0auR wQRrZVgT2Ps9ccOoXzCbNdiuCVVoqZeY+8Y6Uuy9wIGeTPjmsJgkjK3amDylgeDjK39Ef9Z26 ZzL8xGwDGznsdXuDkuIU+W/5HeCQaJkDqpuYQGC+Hsqm3Q2UBZrd5Qf7OLVldHAm99jlI5xXX bqfyW5LOlctQksHOTBElg8EtF7cEGiQMKKYzBR6w8o6m8E2qdgfpzyatZ24rAvr9sijU9iRe8 Ol1fJc2pYX+NxnI5WPFP/38e0iKuLZ9wKriLEmDBZAnbqYj9QZMIGE2Ueia6hJHWg7f1aHapX o6xWsrHTA0gcs3AX265de6ScWyoX4fmLcm84LABB6/Z8yfHiema0+mLyV4sksX7NM9MopilxG 0J5xt8OzkG0098I9sr5siVB3ajveXL1SZ+8ZklAr93lOCD30k50ByT5HofEIY//mUsfU7RAyx 7hdwY1k5P/6uUETYP0lOwAI1pWEE6B/sNsFYRNVJjAtCoBiIoIE6hSN0HttI3J0XgdXKs2bh9 f6BcQTUB4gmCnkvKfKskqh+Kbwn0g5PcEYjpPkn9CxKg8JpKfMDkY/p/KK+KY33ASw9qJ+YC7 iKrq1+qHmCniMwRKxBYtylqZ4BiOxoc5R0wJQrgmW9Zwe1DkiN6Nmwr1Rq6tX9qKSydvdG0vE 44H44J6A89YzL2ut2sPddfAsjBbgRWQY8kaKxFaa9x4w9OAHtwG+cxoqQNBrx2TPPe2yPIexs hx1J/X6mD697E1Mh+hMOL9cjU+sByMBK7ZfKkGKccOq0hTCOZprdsCQtne66pLW6RkYTOHzo6 vnDs81MYz3A== Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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