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 CBDA6C43381 for ; Wed, 6 Mar 2019 11:45:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9182A2064A for ; Wed, 6 Mar 2019 11:45:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729500AbfCFLpi (ORCPT ); Wed, 6 Mar 2019 06:45:38 -0500 Received: from mout.gmx.net ([212.227.17.21]:58999 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728438AbfCFLpi (ORCPT ); Wed, 6 Mar 2019 06:45:38 -0500 Received: from [10.10.11.100] ([95.88.214.118]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MHbpA-1gyDCX1t52-003Ln0; Wed, 06 Mar 2019 12:45:21 +0100 Subject: Re: stmmac / meson8b-dwmac From: Simon Huelck 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: <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> 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: <0d8de157-54ac-aa3b-611d-9657d516190f@gmx.de> Date: Wed, 6 Mar 2019 12:45:07 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:l5AW0TSzz81zWKXY+vZ/ZWtSloQrLd9swODD99XTKpKhuaMsEps ZheAv6S2zlyQq/fkaSMAjpu7wrKHkTDVgJNQmf6uAd02GNtNwbFeJ/rP9rkbUll/rBwT9YH Sh75W0PCwMDAtBikuOBmHZhnlKnDufcqvkQbrUAOOPYXq4pRsFn8Wn0+BGV3QfwtlgCsU7p 8W6AGSHzymde/mbr+nkQQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:xYQXdcr4d3E=:6hmg1ff4jOxYDD1O+64SgR QLOoY+vUwsarjvFb04qTlKOQesTw1yA+6+mv1t/PdbI4qiJLBgTE1LrEPpTfrv6C0PIY9wgu6 T9evvyydA8BAk0eWKRMoVEhVn8o7uYz7aEhBUB9i+1Borhg9akn9DbwkugSK5QSxOZHj6ME3g +cfSYalREn9UFaBti2bHKy10FU7GBV3eRyzVCz3LWQG4op7Sd+O38Z/YgUrwtmdFbHt2nHodP n9/5QEPYRJH8Jr32fr5VTJBrnfHScdfe+ZaOh8Bsik1EExX3ZFraetrzenI2UonlYmtkTd4jp T71ycEeYmbfb7bDMAr1OdJLCcgtyGWqXLwyzoyFFvzZ2hq/S1/ePKOMJiKEXqU24+LqI2UvYv 3sve0KnzljQa+Lr5TcztszmwSI8J4heNPkugn0N1FqNmLytmOJL4mT+GLdXSq7VcETliflsq8 /eklmI0D1ZD7lgXJElL2o1DNc+AGruXEnDtXjUpPzyWfByIaS2zBG9So7hfk1d5UB/PMuAozn UHeBj1Mm/VkfnLN22ysg5pEb+lUA1RXVG0OB0Kmdrn5nweRBknFcpch6EFsS9SNJV/RxVfGY4 g48suHAZ9m2YoA0KpqTOjF3OnIUifa6uAz6LMqp4PXq7Gaz0Wg94LlOd12pt4uUXwmwICc5TU 5bvQjBb225v7g1n78CO/PRGuQz/hosXHhpdMvkVqIItiUGeMtkhgL0ke4bCNNtoXmvrElYw1z l8oLgx7MznZzDEYonqprnvOEVGFHIwlIwNxelPjaqiBp+c4dGKj5/GAX6FnLBLjnJUgNVwp1U cjmpWA/LWj1dbp7jxQaC+adOWYyfBUcMXhFqhCWP/Rpyz0tbW//bOG1g5ymW9I4E30TPAFMqZ +orerQksgRirVP4pEEtR510msiex31eykk+dk7x0tpXoXtuAqMvn19nKNPLGHBfrdzpCw6uB2 fK6V3B9AElg== Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, RX is starving TX i guess ... so the other way around. a transfer was ongoing from 10.10.11.100 to 10.10.11.1 when i triggered this command on 10.10.11.1 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 51652 connected to 10.10.11.100 port 5201 [ ID] Interval           Transfer     Bitrate         Retr  Cwnd [  5]   0.00-1.00   sec   371 KBytes  3.04 Mbits/sec    0   14.3 KBytes [  5]   1.00-2.00   sec   331 KBytes  2.71 Mbits/sec    0   22.8 KBytes [  5]   2.00-3.00   sec   314 KBytes  2.57 Mbits/sec    0   22.8 KBytes [  5]   3.00-4.00   sec   314 KBytes  2.57 Mbits/sec    0   22.8 KBytes [  5]   4.00-5.00   sec   314 KBytes  2.57 Mbits/sec    0   22.8 KBytes [  5]   5.00-6.00   sec   314 KBytes  2.57 Mbits/sec    0   22.8 KBytes [  5]   6.00-7.01   sec  48.0 MBytes   400 Mbits/sec    0    552 KBytes [  5]   7.01-8.00   sec   106 MBytes   896 Mbits/sec    0    874 KBytes [  5]   8.00-9.01   sec   110 MBytes   917 Mbits/sec    0    874 KBytes [  5]   9.01-10.00  sec  98.8 MBytes   833 Mbits/sec   94    637 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bitrate         Retr [  5]   0.00-10.00  sec   365 MBytes   306 Mbits/sec   94             sender [  5]   0.00-10.02  sec   362 MBytes   304 Mbits/sec                  receiver -- root@odroidc2:~# ethtool -S eth0 NIC statistics:      mmc_tx_octetcount_gb: 0      mmc_tx_framecount_gb: 0      mmc_tx_broadcastframe_g: 0      mmc_tx_multicastframe_g: 0      mmc_tx_64_octets_gb: 0      mmc_tx_65_to_127_octets_gb: 0      mmc_tx_128_to_255_octets_gb: 0      mmc_tx_256_to_511_octets_gb: 0      mmc_tx_512_to_1023_octets_gb: 0      mmc_tx_1024_to_max_octets_gb: 0      mmc_tx_unicast_gb: 0      mmc_tx_multicast_gb: 0      mmc_tx_broadcast_gb: 0      mmc_tx_underflow_error: 0      mmc_tx_singlecol_g: 0      mmc_tx_multicol_g: 0      mmc_tx_deferred: 0      mmc_tx_latecol: 0      mmc_tx_exesscol: 0      mmc_tx_carrier_error: 0      mmc_tx_octetcount_g: 0      mmc_tx_framecount_g: 0      mmc_tx_excessdef: 0      mmc_tx_pause_frame: 0      mmc_tx_vlan_frame_g: 0      mmc_rx_framecount_gb: 2039534      mmc_rx_octetcount_gb: 2808094903      mmc_rx_octetcount_g: 2808094903      mmc_rx_broadcastframe_g: 29673      mmc_rx_multicastframe_g: 67      mmc_rx_crc_error: 0      mmc_rx_align_error: 0      mmc_rx_run_error: 0      mmc_rx_jabber_error: 0      mmc_rx_undersize_g: 0      mmc_rx_oversize_g: 0      mmc_rx_64_octets_gb: 0      mmc_rx_65_to_127_octets_gb: 201563      mmc_rx_128_to_255_octets_gb: 656      mmc_rx_256_to_511_octets_gb: 1020      mmc_rx_512_to_1023_octets_gb: 448      mmc_rx_1024_to_max_octets_gb: 1835847      mmc_rx_unicast_g: 2009794      mmc_rx_length_error: 0      mmc_rx_autofrangetype: 0      mmc_rx_pause_frames: 0      mmc_rx_fifo_overflow: 315      mmc_rx_vlan_frames_gb: 2039517      mmc_rx_watchdog_error: 0      mmc_rx_ipc_intr_mask: 1073692671      mmc_rx_ipc_intr: 0      mmc_rx_ipv4_gd: 2010329      mmc_rx_ipv4_hderr: 0      mmc_rx_ipv4_nopay: 0      mmc_rx_ipv4_frag: 0      mmc_rx_ipv4_udsbl: 0      mmc_rx_ipv4_gd_octets: 2760880445      mmc_rx_ipv4_hderr_octets: 0      mmc_rx_ipv4_nopay_octets: 0      mmc_rx_ipv4_frag_octets: 0      mmc_rx_ipv4_udsbl_octets: 0      mmc_rx_ipv6_gd_octets: 10047      mmc_rx_ipv6_hderr_octets: 0      mmc_rx_ipv6_nopay_octets: 0      mmc_rx_ipv6_gd: 22      mmc_rx_ipv6_hderr: 0      mmc_rx_ipv6_nopay: 0      mmc_rx_udp_gd: 7642      mmc_rx_udp_err: 0      mmc_rx_tcp_gd: 2002692      mmc_rx_tcp_err: 0      mmc_rx_icmp_gd: 17      mmc_rx_icmp_err: 0      mmc_rx_udp_gd_octets: 666460      mmc_rx_udp_err_octets: 0      mmc_rx_tcp_gd_octets: 2720015720      mmc_rx_tcp_err_octets: 0      mmc_rx_icmp_gd_octets: 852      mmc_rx_icmp_err_octets: 0      tx_underflow: 0      tx_carrier: 0      tx_losscarrier: 0      vlan_tag: 2039202      tx_deferred: 0      tx_vlan: 1114175      tx_jabber: 0      tx_frame_flushed: 0      tx_payload_error: 0      tx_ip_header_error: 0      rx_desc: 0      sa_filter_fail: 0      overflow_error: 0      ipc_csum_error: 0      rx_collision: 0      rx_crc_errors: 0      dribbling_bit: 0      rx_length: 0      rx_mii: 0      rx_multicast: 0      rx_gmac_overflow: 0      rx_watchdog: 0      da_rx_filter_fail: 0      sa_rx_filter_fail: 0      rx_missed_cntr: 0      rx_overflow_cntr: 0      rx_vlan: 0      tx_undeflow_irq: 0      tx_process_stopped_irq: 0      tx_jabber_irq: 0      rx_overflow_irq: 0      rx_buf_unav_irq: 0      rx_process_stopped_irq: 0      rx_watchdog_irq: 0      tx_early_irq: 0      fatal_bus_error_irq: 0      rx_early_irq: 29321      threshold: 1      tx_pkt_n: 1114175      rx_pkt_n: 2039219      normal_irq_n: 167679      rx_normal_irq_n: 128772      napi_poll: 184569      tx_normal_irq_n: 42982      tx_clean: 55788      tx_set_ic_bit: 44567      irq_receive_pmt_irq_n: 0      mmc_tx_irq_n: 0      mmc_rx_irq_n: 0      mmc_rx_csum_offload_irq_n: 0      irq_tx_path_in_lpi_mode_n: 15749      irq_tx_path_exit_lpi_mode_n: 15748      irq_rx_path_in_lpi_mode_n: 0      irq_rx_path_exit_lpi_mode_n: 0      phy_eee_wakeup_error_n: 0      ip_hdr_err: 0      ip_payload_err: 0      ip_csum_bypassed: 0      ipv4_pkt_rcvd: 0      ipv6_pkt_rcvd: 0      no_ptp_rx_msg_type_ext: 0      ptp_rx_msg_type_sync: 0      ptp_rx_msg_type_follow_up: 0      ptp_rx_msg_type_delay_req: 0      ptp_rx_msg_type_delay_resp: 0      ptp_rx_msg_type_pdelay_req: 0      ptp_rx_msg_type_pdelay_resp: 0      ptp_rx_msg_type_pdelay_follow_up: 0      ptp_rx_msg_type_announce: 0      ptp_rx_msg_type_management: 0      ptp_rx_msg_pkt_reserved_type: 0      ptp_frame_type: 0      ptp_ver: 0      timestamp_dropped: 0      av_pkt_rcvd: 0      av_tagged_pkt_rcvd: 0      vlan_tag_priority_val: 0      l3_filter_match: 0      l4_filter_match: 0      l3_l4_filter_no_match: 0      irq_pcs_ane_n: 0      irq_pcs_link_n: 0      irq_rgmii_n: 0      mtl_tx_status_fifo_full: 0      mtl_tx_fifo_not_empty: 0      mmtl_fifo_ctrl: 0      mtl_tx_fifo_read_ctrl_write: 0      mtl_tx_fifo_read_ctrl_wait: 0      mtl_tx_fifo_read_ctrl_read: 0      mtl_tx_fifo_read_ctrl_idle: 0      mac_tx_in_pause: 0      mac_tx_frame_ctrl_xfer: 0      mac_tx_frame_ctrl_idle: 0      mac_tx_frame_ctrl_wait: 0      mac_tx_frame_ctrl_pause: 0      mac_gmii_tx_proto_engine: 0      mtl_rx_fifo_fill_level_full: 0      mtl_rx_fifo_fill_above_thresh: 0      mtl_rx_fifo_fill_below_thresh: 0      mtl_rx_fifo_fill_level_empty: 0      mtl_rx_fifo_read_ctrl_flush: 0      mtl_rx_fifo_read_ctrl_read_data: 0      mtl_rx_fifo_read_ctrl_status: 0      mtl_rx_fifo_read_ctrl_idle: 0      mtl_rx_fifo_ctrl_active: 0      mac_rx_frame_ctrl_fifo: 0      mac_gmii_rx_proto_engine: 0      tx_tso_frames: 0      tx_tso_nfrags: 0 regards, Simon Am 06.03.2019 um 12:35 schrieb Simon Huelck: > 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