From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Daniel Golle <daniel@makrotopia.org>,
DENG Qingfang <dqfext@gmail.com>, Greg Ungerer <gerg@kernel.org>,
Richard van Schagen <richard@routerhints.com>,
Richard van Schagen <vschagen@cs.com>,
Frank Wunderlich <frank-w@public-files.de>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
bartel.eerdekens@constell8.be, netdev <netdev@vger.kernel.org>
Subject: Re: MT7530 bug, forward broadcast and unknown frames to the correct CPU port
Date: Tue, 16 May 2023 23:01:02 +0300 [thread overview]
Message-ID: <6c83136a-8303-7e3b-9f3f-e214e2bfc66f@arinc9.com> (raw)
In-Reply-To: <20230510140258.44oobynufb3auzw2@skbuf>
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ç
next prev parent reply other threads:[~2023-05-16 20:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-23 15:22 MT7530 bug, forward broadcast and unknown frames to the correct CPU port Arınç ÜNAL
2023-04-26 20:54 ` Vladimir Oltean
2023-04-28 13:31 ` Arınç ÜNAL
2023-04-29 13:03 ` Arınç ÜNAL
2023-04-29 17:35 ` Vladimir Oltean
2023-04-29 18:39 ` Arınç ÜNAL
2023-04-29 18:44 ` Arınç ÜNAL
2023-04-29 18:56 ` Vladimir Oltean
2023-04-29 19:52 ` Arınç ÜNAL
2023-05-01 10:09 ` Vladimir Oltean
2023-05-01 10:31 ` Daniel Golle
2023-05-01 10:43 ` Arınç ÜNAL
2023-05-10 8:59 ` Arınç ÜNAL
2023-05-10 14:02 ` Vladimir Oltean
2023-05-16 20:01 ` Arınç ÜNAL [this message]
2023-05-17 15:52 ` Vladimir Oltean
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=6c83136a-8303-7e3b-9f3f-e214e2bfc66f@arinc9.com \
--to=arinc.unal@arinc9.com \
--cc=bartel.eerdekens@constell8.be \
--cc=daniel@makrotopia.org \
--cc=dqfext@gmail.com \
--cc=erkin.bozoglu@xeront.com \
--cc=frank-w@public-files.de \
--cc=gerg@kernel.org \
--cc=mithat.guner@xeront.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=richard@routerhints.com \
--cc=vschagen@cs.com \
/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