Re: MT7530 bug, forward broadcast and unknown frames to the correct CPU port

Daniel Golle
2023-05-01T10:32:09Z

On Mon, May 01, 2023 at 01:09:30PM +0300, Vladimir Oltean wrote:
> On Sat, Apr 29, 2023 at 10:52:12PM +0300, Arınç ÜNAL wrote:
> > On 29.04.2023 21:56, Vladimir Oltean wrote:
> > > On Sat, Apr 29, 2023 at 09:39:41PM +0300, Arınç ÜNAL wrote:
> > > > Are you fine with the preferred port patch now that I mentioned port 6
> > > > would be preferred for MT7531BE since it's got 2.5G whilst port 5 has
> > > > got 1G? Would you like to submit it or leave it to me to send the diff
> > > > above and this?
> > >
> > > No, please tell me: what real life difference would it make to a user
> > > who doesn't care to analyze which CPU port is used?
> >
> > They would get 2.5 Gbps download/upload bandwidth in total to the CPU,
> > instead of 1 Gbps. 3 computers connected to 3 switch ports would each get
> > 833 Mbps download/upload speed to/from the CPU instead of 333 Mbps.
>
> In theory, theory and practice are the same. In practice, they aren't.
> Are you able to obtain 833 Mbps concurrently over 3 user ports?

Probably the 2.5 GBit/s won't saturate, but I do manage to get more
than 1 Gbit/s total (using the hardware flow offloading capability to
NAT-route WAN<->LAN and simultanously have a WiFi client access a NAS
device which also connects to a LAN port. I use MT7915E+MT7975D mPCIe
module with BPi-R2)

Using PHY muxing to directly map the WAN port to GMAC2 is also an
option, but would be limiting the bandwidth for those users who just
want all 5 ports to be bridged. Hence I do agree with Arınç that the
best would be to use the TRGMII link on GMAC1 for the 4 WAN ports and
prefer using RGMII link on GMAC2 for the WAN port, but keep using DSA.