Aw: Re: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2

[Arınç ÜNAL]

On 4.02.2023 16:07, Frank Wunderlich wrote:
> Hi
> 
>> Gesendet: Samstag, 04. Februar 2023 um 13:12 Uhr
>> Von: "Arınç ÜNAL" <arinc.unal at arinc9.com>
>> An: "Frank Wunderlich" <frank-w at public-files.de>
>> Cc: arinc9.unal at gmail.com, "Rob Herring" <robh+dt at kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt at linaro.org>, "Matthias Brugger" <matthias.bgg at gmail.com>, devicetree at vger.kernel.org, linux-arm-kernel at lists.infradead.org, linux-mediatek at lists.infradead.org, linux-kernel at vger.kernel.org, erkin.bozoglu at xeront.com, "Sean Wang" <sean.wang at mediatek.com>, "DENG Qingfang" <dqfext at gmail.com>
>> Betreff: Re: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>
>> On 4.02.2023 14:43, Frank Wunderlich wrote:
>>>> Gesendet: Samstag, 04. Februar 2023 um 11:27 Uhr
>>>> Von: "Frank Wunderlich" <frank-w at public-files.de>
>>>> An: "Arınç ÜNAL" <arinc.unal at arinc9.com>
>>>> Cc: arinc9.unal at gmail.com, "Rob Herring" <robh+dt at kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt at linaro.org>, "Matthias Brugger" <matthias.bgg at gmail.com>, devicetree at vger.kernel.org, linux-arm-kernel at lists.infradead.org, linux-mediatek at lists.infradead.org, linux-kernel at vger.kernel.org, erkin.bozoglu at xeront.com, "Sean Wang" <sean.wang at mediatek.com>, "DENG Qingfang" <dqfext at gmail.com>
>>>> Betreff: Aw: Re: [PATCH v2 4/5] arm: dts: mt7623: mux phy0 on Bananapi BPI-R2
>>>>
>>>> Hi aranc,
>>>>
>>>> have tested this series, basicly it works, but i get only ~620 Mbits/sec (much more i will need on wan) in tx-mode of r2, rx-mode (iperf3 -c IP -R on r2) gets full 939 Mbits/sec. Both no retransmitts.
>>>>
>>>> tried with my laptop which gets 940Mbit/sec in tx mode too...other end is a R2 with 5.15 connected to lan0 (and eth1+aux enabled, dmesg clean so far...for the "kernel log flooded"-comment).
>>>>
>>>> maybe gmac1 needs to be tweaked a bit (clock-settings)?
>>>>
>>>> can you confirm this with your board?
>>>
>>> tested the vlan_aware way with 5.15.80 and got better result
>>>
>>> ip link add br0 type bridge vlan_filtering 1
>>> ip l set aux master br0
>>> ip l set wan master br0
>>> bridge vlan add vid 99 dev wan
>>> bridge vlan add vid 99 dev aux
>>> bridge vlan
>>> ip l s eth1 up
>>> ip l s wan up
>>> ip a a 192.168.0.11/24 dev eth1
>>> ip l s br0 up
>>> ip l s aux up
>>>
>>> i see traffic on eth1 increasing and iperf3 shows in both directions ~940Mbit/s, no strange mesages in dmesg while testing...where do you see these?
>>
>> You didn't put eth1 on a bridge. I suggest you read my mails with higher
>> attention so both of our time is spent efficiently.
> 
> sorry if i misseed this detail, but it was not part of the instructions i got from mtk and did not found it in our mail-conversion. why do i need to add the gmac into the bridge??

I was going to say, to put the host(s) connected to the wan port on the 
same network as other ports, but using the wan interface for that 
instead would work. Cool, we can cross this off the list.

> 
> the gmac is connected physically to mt7531 p5, and my vlan_aware bridge bridges this port (aux=p5) with wan,
> so i see no need to add eth1 to this bridge too...traffic on wan is tagged with vlan 99 and leaving untagged
> on aux which is arriving eth1...
> 
>>> tested vlan-way with 6.2 and felix' Patches to more comparable with your test...and got same result (~625Mbit/s in tx and 940Mbit/s in rx-mode=-R on r2)...so it seems anything between 5.15 and 6.2 reduced gmac1 tx bandwidth.
>>
>> I don't see an incentive to investigate unless the issue is confirmed on
>> a daily netdev/net-next.git main tree.
> 
> have same result on net-next/main with your series, no additional patches on top except adding my build-script and defconfig.

Finding the cause of reduced network performance is quite a challenging 
task. The only person I know that gives this a serious approach is Rafał 
Miłecki. There are scripts and things they share on the openwrt-devel 
mailing list along with details of their investigation, usually for 
Broadcom SoCs.

I'm no good in this so I'm not going to do anything about it. There are 
issues with the MediaTek ethernet and MT7530 DSA subdriver that 
completely break communication which I want to have them addressed.

Arınç