[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c83136a-8303-7e3b-9f3f-e214e2bfc66f@arinc9.com>
Date: Tue, 16 May 2023 23:01:02 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Daniel Golle <daniel@...rotopia.org>, DENG Qingfang <dqfext@...il.com>,
Greg Ungerer <gerg@...nel.org>, Richard van Schagen
<richard@...terhints.com>, Richard van Schagen <vschagen@...com>,
Frank Wunderlich <frank-w@...lic-files.de>, mithat.guner@...ont.com,
erkin.bozoglu@...ont.com, bartel.eerdekens@...stell8.be,
netdev <netdev@...r.kernel.org>
Subject: Re: MT7530 bug, forward broadcast and unknown frames to the correct
CPU port
On 10.05.2023 17:02, Vladimir Oltean wrote:
> On Wed, May 10, 2023 at 10:59:36AM +0200, Arınç ÜNAL wrote:
>>> You seem to be rather talking about MT7530 while I think preferring port 6
>>> would benefit MT7531BE the most.
>>>
>>> Can you test the actual speed with SGMII on MT7531? Route between two ports and
>>> do a bidirectional iperf3 speed test.
>>>
>>> SGMII should at least provide you with 2 Gbps bandwidth in total in a
>>> router-on-a-stick scenario which is the current situation until the changing
>>> DSA conduit support is added.
>>>
>>> If we were to use port 5, download and upload speed would be capped at 500
>>> Mbps. With SGMII you should get 1000 Mbps on each.
>>
>> I tested this on Daniel's Banana Pi BPI-R3 which has got an MT7531AE switch.
>> I can confirm I get more than 500 Mbps for RX and TX on a bidirectional
>> speed test.
>>
>> [SUM][RX-S] 0.00-18.00 sec 1.50 GBytes 715 Mbits/sec receiver
>>
>> [SUM][TX-S] 0.00-18.00 sec 1.55 GBytes 742 Mbits/sec 6996 sender
>>
>> The test was run between two computers on different networks, 192.168.1.0/24
>> and 192.168.2.0/24, both computers had static routes to reach each other. I
>> tried iperf3 as the server and client on both computers with similar
>> results.
>>
>> This concludes preferring port 6 is practically beneficial for MT7531BE.
>
> One thing you seem to not realize is that "1 Gbit/sec full duplex" means
> that there is 1Gbps of bandwidth in the TX direction and 1 Gbps of
> bandwidth of throughput in the RX direction. So, I don't see how your
> test proves anything, since a single SGMII full duplex link to the CPU
> should be able to absorb your 715 RX + 742 TX traffic just fine.
I'm talking about 1 Gbps TX and RX (bidirectional) traffic between two
DSA user ports. We're doing routing so bridge offloading is out of
question. In this case, the SoC MAC would have to do 2 Gbps TX and 2
Gbps RX.
I have a BPI-R64 with an MT7531BE at home now, thanks to Daniel's folks.
Here's the iperf3 bidirectional test result:
Without preferring port 6:
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-20.00 sec 374 MBytes 157 Mbits/sec 734
sender
[ 5][TX-C] 0.00-20.00 sec 373 MBytes 156 Mbits/sec
receiver
[ 7][RX-C] 0.00-20.00 sec 1.81 GBytes 778 Mbits/sec 0
sender
[ 7][RX-C] 0.00-20.00 sec 1.81 GBytes 777 Mbits/sec
receiver
With preferring port 6:
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-20.00 sec 1.99 GBytes 856 Mbits/sec 273
sender
[ 5][TX-C] 0.00-20.00 sec 1.99 GBytes 855 Mbits/sec
receiver
[ 7][RX-C] 0.00-20.00 sec 1.72 GBytes 737 Mbits/sec 15
sender
[ 7][RX-C] 0.00-20.00 sec 1.71 GBytes 736 Mbits/sec
receiver
This scenario is quite popular as you would see a lot of people using
one port for WAN and the other ports for LAN.
Therefore, the "prefer local CPU port" operation would be useful. If you
can introduce the operation to the DSA subsystem, I will make a patch to
start using it on the MT7530 DSA subdriver.
Arınç
Powered by blists - more mailing lists