public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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ç

  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