arch/arm/boot/dts/mt7623.dtsi | 12 +++ arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 86 +++++-------------- arch/arm/boot/dts/mt7623a-rfb-nand.dts | 86 +++++-------------- arch/arm/boot/dts/mt7623a.dtsi | 99 ++++++++++++++++++++++ arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 49 ++++++++--- arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 37 ++++---- 6 files changed, 207 insertions(+), 162 deletions(-)
Γεια σας και πάλι! We're doing cleanup and adding port@5 as a CPU port. The main takeaway of the cleanup is that the MT7530 switch is actually a part of the multi-chip module on the MT7623AI SoC. I'm moving the bindings for this switch to mt7623a.dtsi so they don't need to be defined on every device with this SoC. This should ease it up for supporting more devices with MT7623AI SoC on mainline. I don't know if there's a pin wired for interrupt. The switch is going to work with polling for the time being. Folks from MediaTek, feel free to fill us in on this. I've tested the CPU ports on my Bananapi BPI-R2. DTs compile fine. v3: - Drop phy muxing, add port@5 as a CPU port instead. v2: - Do not define phy-mode on mt7623.dtsi, it should be defined on the DTs that call mt7623.dtsi instead. - Use the labels for the MACs, remove them from under ð on the DTs that call mt7623.dtsi. - Mention on the log of the forth patch that the interface name will change from wan to eth1. Arınç ÜNAL (5): arm: dts: mt7623: add gmacs to mt7623.dtsi arm: dts: mt7623: add mt7530 switch to mt7623a.dtsi arm: dts: mt7623: change mt7530 switch address arm: dts: mt7623: enable flow control on port@6 arm: dts: mt7623: add port@5 as CPU port arch/arm/boot/dts/mt7623.dtsi | 12 +++ arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 86 +++++-------------- arch/arm/boot/dts/mt7623a-rfb-nand.dts | 86 +++++-------------- arch/arm/boot/dts/mt7623a.dtsi | 99 ++++++++++++++++++++++ arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 49 ++++++++--- arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 37 ++++---- 6 files changed, 207 insertions(+), 162 deletions(-)
Frank, I think Matthias is waiting for your approval on this patch series. Is this series fine by you? Arınç
Hi, finally get some time to bootup with this series on my r2. I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice. But it look worse...network is currently broken (set both gmacs up). I see arp-packets reaching remote side, but reponse is not received by r2 I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right. so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result... i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is cpu-port again and it works...so something is wrong with port5 of switch or gmac1. regards Frank
On 18.02.2023 13:24, Frank Wunderlich wrote: > Hi, > > finally get some time to bootup with this series on my r2. > > I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as > default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice. > > But it look worse...network is currently broken (set both gmacs up). > I see arp-packets reaching remote side, but reponse is not received by r2 > > I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right. > > so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result... > > i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is > cpu-port again and it works...so something is wrong with port5 of switch or gmac1. That's a driver issue and will be fixed once an accepted version of these patches [0] [1] [2] are applied to net-next. You should have them on your inbox, I specifically told Richard to CC you. This is devicetree bindings. We're here to describe the hardware. The way a driver works should not affect describing the hardware. To address the lower bandwidth situation you mentioned, a devicetree property to designate a CPU port as the default CPU port could be introduced. I'm not aware of a similar conversation so I'll send a mail to netdev to discuss this. Will CC you. [0] https://lore.kernel.org/netdev/20230212213949.672443-1-richard@routerhints.com/ [1] https://lore.kernel.org/netdev/20230212214027.672501-1-richard@routerhints.com/ [2] https://lore.kernel.org/netdev/20230212215152.673221-1-richard@routerhints.com/ Arınç
Hi, > Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr > Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> > An: "Frank Wunderlich" <frank-w@public-files.de> > On 18.02.2023 13:24, Frank Wunderlich wrote: > > Hi, > > > > finally get some time to bootup with this series on my r2. > > > > I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as > > default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice. > > > > But it look worse...network is currently broken (set both gmacs up). > > I see arp-packets reaching remote side, but reponse is not received by r2 > > > > I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right. > > > > so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result... > > > > i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is > > cpu-port again and it works...so something is wrong with port5 of switch or gmac1. > > That's a driver issue and will be fixed once an accepted version of > these patches [0] [1] [2] are applied to net-next. You should have them > on your inbox, I specifically told Richard to CC you. yes, i've got them, but not applied when starting these tests. Not thought, that this change is necessary as we use both gmac on mt7531/bpi-r3 with out problems. with these 3 Patches network-connection works, but only at ~624 Mbit/s in TX-Mode (started iperf3-client on r2 without -R) and massive retransmitts on first run, other direction is clean. and these Patches need to be applied first (when fixed up) else network is broken. > This is devicetree bindings. We're here to describe the hardware. The > way a driver works should not affect describing the hardware. thats right, but it should not break/change behaviour like now all ports have only ~600Mbit because of moving them all to the other gmac which has obvious issues. > To address the lower bandwidth situation you mentioned, a devicetree > property to designate a CPU port as the default CPU port could be > introduced. I'm not aware of a similar conversation so I'll send a mail > to netdev to discuss this. Will CC you. isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)? maybe moving port5 below port6...not nice, but then port6 is the first cpu found. or maybe defined the default cpu in driver which gets picked up by core (define port6 if available as default). Imho additional dts-propperty is wrong approch...it should be handled by driver. But cpu-port-selection is currently done in dsa-core which makes it a bit difficult. I'm not sure how the multi-cpu support in dsa-core ended and how you use the other gmac not used by dsa-core set master in userspace-config? i remember you've sent a patch adding callback for it. imho dts change should be applied if these points are cleared... regards Frank
On 18.02.2023 15:18, Frank Wunderlich wrote: > Hi, > >> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr >> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >> An: "Frank Wunderlich" <frank-w@public-files.de> > >> On 18.02.2023 13:24, Frank Wunderlich wrote: >>> Hi, >>> >>> finally get some time to bootup with this series on my r2. >>> >>> I see that inserting the port@5 as cpu-port maps this as default-cpu because dsa-core uses first found cpu-port as >>> default (dsa_tree_setup_cpu_ports in dsa.c) and because of lower bandwidth (rgmii instead of trgmii) not the best choice. >>> >>> But it look worse...network is currently broken (set both gmacs up). >>> I see arp-packets reaching remote side, but reponse is not received by r2 >>> >>> I have tested it on 6.2-rc8 (wan-port), maybe additional patches are needed?...userspace setup should be right. >>> >>> so i added series on top of net-next (no additional patches except some basic like build-script,defconfig and such)...same result... >>> >>> i'm not sure if i change the mapping from userspace back to eth0, so disabled port@5 in switch, now port6 is >>> cpu-port again and it works...so something is wrong with port5 of switch or gmac1. >> >> That's a driver issue and will be fixed once an accepted version of >> these patches [0] [1] [2] are applied to net-next. You should have them >> on your inbox, I specifically told Richard to CC you. > > yes, i've got them, but not applied when starting these tests. Not thought, that this change is necessary > as we use both gmac on mt7531/bpi-r3 with out problems. > > with these 3 Patches network-connection works, but only at ~624 Mbit/s in TX-Mode (started iperf3-client on r2 without -R) and massive retransmitts on first run, other direction is clean. Ok, so according to your tests, traffic through gmac1 is not very good. gmac0 should be the default DSA master. By the way, did you make a bug report of this, by sending a mail to netdev mailing list or some other way? > > and these Patches need to be applied first (when fixed up) else network is broken. That's true. > >> This is devicetree bindings. We're here to describe the hardware. The >> way a driver works should not affect describing the hardware. > > thats right, but it should not break/change behaviour like now all ports have only ~600Mbit because of > moving them all to the other gmac which has obvious issues. Makes sense. > >> To address the lower bandwidth situation you mentioned, a devicetree >> property to designate a CPU port as the default CPU port could be >> introduced. I'm not aware of a similar conversation so I'll send a mail >> to netdev to discuss this. Will CC you. > > isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)? > maybe moving port5 below port6...not nice, but then port6 is the first cpu found. This could be done but it comes off as an improper way to me. > or maybe defined the default cpu in driver which gets picked up by core (define port6 if available as default). > Imho additional dts-propperty is wrong approch...it should be handled by driver. But cpu-port-selection is > currently done in dsa-core which makes it a bit difficult. > > I'm not sure how the multi-cpu support in dsa-core ended and how you use the other gmac not used by dsa-core > > set master in userspace-config? i remember you've sent a patch adding callback for it. You can change the DSA master using iproute2-6.1.0 and above with this patch which should be in your inbox as well. https://lore.kernel.org/netdev/20230211184101.651462-1-richard@routerhints.com/ > > imho dts change should be applied if these points are cleared... The only issue I see here is that, with this patch series, port5 becomes the default CPU port which is not preferred for the reasons you explained. So once we can have port6 to be the default CPU port of the DSA slaves, there's no issues left. Arınç
Am 18. Februar 2023 18:02:11 MEZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>: >On 18.02.2023 15:18, Frank Wunderlich wrote: >> Hi, >> >>> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr >>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >>> An: "Frank Wunderlich" <frank-w@public-files.de> >> >>> On 18.02.2023 13:24, Frank Wunderlich wrote: >Ok, so according to your tests, traffic through gmac1 is not very good. gmac0 should be the default DSA master. >By the way, did you make a bug report of this, by sending a mail to netdev mailing list or some other way? No,not yet, because gmac1 is not yet used and i had very limited time. I'm not sure it is an issue in mt7530 driver or mtk_soc_eth, not idea how to figure this out. Maybe it can be fixed with a delayed rgmii phy-mode (rgmii-rx-id i guess as traffic affected is rx on switch,tx on gmac). >> isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)? >> maybe moving port5 below port6...not nice, but then port6 is the first cpu found. > >This could be done but it comes off as an improper way to me. Just thought about a way without the need of changing driver or adding a new dt property which can be wrongly used (who prevents anybody set the "default-cpu" property on more than 1 cpu-port?), Or define it at switch node level not port level (e.g. via phandle). If the 5-below-6 way is not the right one i would prefer a driver solution, e.g. let driver choose the best cpu based on fixed value (constant via define) or on highest throughput (trgmii > rgmii),but last may fail if both cpu-ports have same speed like mt7531. These are the possible solutions i see atm. Maybe dsa people can share their opinion. >> set master in userspace-config? i remember you've sent a patch adding callback for it. > >You can change the DSA master using iproute2-6.1.0 and above with this patch which should be in your inbox as well. > >https://lore.kernel.org/netdev/20230211184101.651462-1-richard@routerhints.com/ I try to test it. >The only issue I see here is that, with this patch series, port5 becomes the default CPU port which is not preferred for the reasons you explained. > >So once we can have port6 to be the default CPU port of the DSA slaves, there's no issues left. For me this would be ok if the current configuration does not change, right :) Thx for your work. regards Frank
On 18.02.2023 22:11, Frank Wunderlich wrote:
> Am 18. Februar 2023 18:02:11 MEZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>:
>> On 18.02.2023 15:18, Frank Wunderlich wrote:
>>> Hi,
>>>
>>>> Gesendet: Samstag, 18. Februar 2023 um 11:49 Uhr
>>>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
>>>> An: "Frank Wunderlich" <frank-w@public-files.de>
>>>
>>>> On 18.02.2023 13:24, Frank Wunderlich wrote:
>
>> Ok, so according to your tests, traffic through gmac1 is not very good. gmac0 should be the default DSA master.
>
>> By the way, did you make a bug report of this, by sending a mail to netdev mailing list or some other way?
>
> No,not yet, because gmac1 is not yet used and i had very limited time. I'm not sure it is an issue in mt7530 driver or mtk_soc_eth, not idea how to figure this out. Maybe it can be fixed with a delayed rgmii phy-mode (rgmii-rx-id i guess as traffic affected is rx on switch,tx on gmac).
My experience with rgmii delays is that if the correct delay is not set
for tx or rx, that tx or rx will just not work at all. But testing it
anyway won't hurt.
Can you also remove this from mt7530.c and do the test again? See if the
performance changes at all.
/* Set core clock into 500Mhz */
core_write(priv, CORE_GSWPLL_GRP2,
RG_GSWPLL_POSDIV_500M(1) |
RG_GSWPLL_FBKDIV_500M(25));
>
>>> isn't there a way to leave ports by default on the the better gmac (gmac0=trgmii)?
>>> maybe moving port5 below port6...not nice, but then port6 is the first cpu found.
>>
>> This could be done but it comes off as an improper way to me.
>
> Just thought about a way without the need of changing driver or adding a new dt property which can be wrongly used (who prevents anybody set the "default-cpu" property on more than 1 cpu-port?), Or define it at switch node level not port level (e.g. via phandle).
This is why we write json-schema documentation.
>
> If the 5-below-6 way is not the right one i would prefer a driver solution, e.g. let driver choose the best cpu based on fixed value (constant via define) or on highest throughput (trgmii > rgmii),but last may fail if both cpu-ports have same speed like mt7531.
>
> These are the possible solutions i see atm. Maybe dsa people can share their opinion.
You should share your opinion on my mail to netdev mailing list I
recently CC'd you.
>
>>> set master in userspace-config? i remember you've sent a patch adding callback for it.
>>
>> You can change the DSA master using iproute2-6.1.0 and above with this patch which should be in your inbox as well.
>>
>> https://lore.kernel.org/netdev/20230211184101.651462-1-richard@routerhints.com/
>
> I try to test it.
>
>> The only issue I see here is that, with this patch series, port5 becomes the default CPU port which is not preferred for the reasons you explained.
>>
>> So once we can have port6 to be the default CPU port of the DSA slaves, there's no issues left.
>
> For me this would be ok if the current configuration does not change, right :)
Userspace configuration won't change, not with the current patch, not ever.
Arınç
> Gesendet: Samstag, 18. Februar 2023 um 20:34 Uhr > Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> > An: frank-w@public-files.de > On 18.02.2023 22:11, Frank Wunderlich wrote: > > Am 18. Februar 2023 18:02:11 MEZ schrieb "Arınç ÜNAL" <arinc.unal@arinc9.com>: > >> On 18.02.2023 15:18, Frank Wunderlich wrote: > Can you also remove this from mt7530.c and do the test again? See if the > performance changes at all. > > /* Set core clock into 500Mhz */ > core_write(priv, CORE_GSWPLL_GRP2, > RG_GSWPLL_POSDIV_500M(1) | > RG_GSWPLL_FBKDIV_500M(25)); > with these disabled i have a bit better performance (625 Mbits/sec instead of 600) and no retransmitts on first iperf3-run. not yet tried any rgmii-delay option (have no idea which is the right one on which position), but yes, mostly it does not improve performance...it simply does work or does not work. regards Frank
Hi, retested series on bananpi r2 on 6.3-rc6 (after throughput is fixed for mt7623/trgmii too) with additional patches: "net: dsa: implement preferred cpu port handling" by Vladimir Oltean to stay on gmac0 by default "net: dsa: mt7530: add support for changing DSA master" by Richard van Schagen looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one... any idea how the correct syntax is for iproute2? at least vladimirs patch should be included when applying this series regards Frank
On 12.04.2023 15:49, Frank Wunderlich wrote: > Hi, > > retested series on bananpi r2 on 6.3-rc6 (after throughput is fixed for mt7623/trgmii too) with additional patches: > > "net: dsa: implement preferred cpu port handling" by Vladimir Oltean to stay on gmac0 by default > "net: dsa: mt7530: add support for changing DSA master" by Richard van Schagen > > looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one... > any idea how the correct syntax is for iproute2? https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports In short: ip link set lan0 type dsa conduit eth1 > > at least vladimirs patch should be included when applying this series I'm currently cleaning up the DSA driver, I'll get to this at some point. Arınç
Hi
> Gesendet: Mittwoch, 12. April 2023 um 16:31 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> > looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one...
> > any idea how the correct syntax is for iproute2?
>
> https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports
>
> In short: ip link set lan0 type dsa conduit eth1
thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1...
5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.11/24 scope global wan
valid_lft forever preferred_lft forever
see no p5-TX/gmac-rx
root@bpi-r2:~# ethtool -S eth1
NIC statistics:
tx_bytes: 5156
tx_packets: 61
tx_skip: 0
tx_collisions: 0
rx_bytes: 0
rx_packets: 0
rx_overflow: 0
rx_fcs_errors: 0
rx_short_errors: 0
rx_long_errors: 0
rx_checksum_errors: 0
rx_flow_control_packets: 0
rx_xdp_redirect: 0
rx_xdp_pass: 0
rx_xdp_drop: 0
rx_xdp_tx: 0
rx_xdp_tx_errors: 0
tx_xdp_xmit: 0
tx_xdp_xmit_errors: 0
p05_TxDrop: 0
p05_TxCrcErr: 0
p05_TxUnicast: 0
p05_TxMulticast: 0
p05_TxBroadcast: 0
p05_TxCollision: 0
p05_TxSingleCollision: 0
p05_TxMultipleCollision: 0
p05_TxDeferred: 0
p05_TxLateCollision: 0
p05_TxExcessiveCollistion: 0
p05_TxPause: 0
p05_TxPktSz64: 0
p05_TxPktSz65To127: 0
p05_TxPktSz128To255: 0
p05_TxPktSz256To511: 0
p05_TxPktSz512To1023: 0
p05_Tx1024ToMax: 0
p05_TxBytes: 0
p05_RxDrop: 0
p05_RxFiltering: 16
p05_RxUnicast: 11
p05_RxMulticast: 38
p05_RxBroadcast: 12
p05_RxAlignErr: 0
p05_RxCrcErr: 0
p05_RxUnderSizeErr: 0
p05_RxFragErr: 0
p05_RxOverSzErr: 0
p05_RxJabberErr: 0
p05_RxPause: 0
p05_RxPktSz64: 17
p05_RxPktSz65To127: 44
p05_RxPktSz128To255: 0
p05_RxPktSz256To511: 0
p05_RxPktSz512To1023: 0
p05_RxPktSz1024ToMax: 0
p05_RxBytes: 5156
p05_RxCtrlDrop: 0
p05_RxIngressDrop: 0
p05_RxArlDrop: 0
maybe i miss something?
i'm not sure it is a problem with richards Patch or p5/gmac1
> > at least vladimirs patch should be included when applying this series
>
> I'm currently cleaning up the DSA driver, I'll get to this at some point.
regards Frank
On 12.04.2023 18:11, Frank Wunderlich wrote: > Hi > >> Gesendet: Mittwoch, 12. April 2023 um 16:31 Uhr >> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >>> looks good so far, but i have not managed how to change dsa master from the preferred port (eth0) to the second one... >>> any idea how the correct syntax is for iproute2? >> >> https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#affinity-of-user-ports-to-cpu-ports >> >> In short: ip link set lan0 type dsa conduit eth1 > > thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1... > > 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 > link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff > inet 192.168.0.11/24 scope global wan > valid_lft forever preferred_lft forever > > see no p5-TX/gmac-rx > > root@bpi-r2:~# ethtool -S eth1 > NIC statistics: > tx_bytes: 5156 > tx_packets: 61 > tx_skip: 0 > tx_collisions: 0 > rx_bytes: 0 > rx_packets: 0 > rx_overflow: 0 > rx_fcs_errors: 0 > rx_short_errors: 0 > rx_long_errors: 0 > rx_checksum_errors: 0 > rx_flow_control_packets: 0 > rx_xdp_redirect: 0 > rx_xdp_pass: 0 > rx_xdp_drop: 0 > rx_xdp_tx: 0 > rx_xdp_tx_errors: 0 > tx_xdp_xmit: 0 > tx_xdp_xmit_errors: 0 > p05_TxDrop: 0 > p05_TxCrcErr: 0 > p05_TxUnicast: 0 > p05_TxMulticast: 0 > p05_TxBroadcast: 0 > p05_TxCollision: 0 > p05_TxSingleCollision: 0 > p05_TxMultipleCollision: 0 > p05_TxDeferred: 0 > p05_TxLateCollision: 0 > p05_TxExcessiveCollistion: 0 > p05_TxPause: 0 > p05_TxPktSz64: 0 > p05_TxPktSz65To127: 0 > p05_TxPktSz128To255: 0 > p05_TxPktSz256To511: 0 > p05_TxPktSz512To1023: 0 > p05_Tx1024ToMax: 0 > p05_TxBytes: 0 > p05_RxDrop: 0 > p05_RxFiltering: 16 > p05_RxUnicast: 11 > p05_RxMulticast: 38 > p05_RxBroadcast: 12 > p05_RxAlignErr: 0 > p05_RxCrcErr: 0 > p05_RxUnderSizeErr: 0 > p05_RxFragErr: 0 > p05_RxOverSzErr: 0 > p05_RxJabberErr: 0 > p05_RxPause: 0 > p05_RxPktSz64: 17 > p05_RxPktSz65To127: 44 > p05_RxPktSz128To255: 0 > p05_RxPktSz256To511: 0 > p05_RxPktSz512To1023: 0 > p05_RxPktSz1024ToMax: 0 > p05_RxBytes: 5156 > p05_RxCtrlDrop: 0 > p05_RxIngressDrop: 0 > p05_RxArlDrop: 0 > > maybe i miss something? > > i'm not sure it is a problem with richards Patch or p5/gmac1 Did you apply the vlan and flooding fix patches from Richard? Arınç
Hi
> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com>
> > thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1...
> >
> > 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> > link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
> > inet 192.168.0.11/24 scope global wan
> > valid_lft forever preferred_lft forever
> >
> > see no p5-TX/gmac-rx
> Did you apply the vlan and flooding fix patches from Richard?
have now applied all patches i've found from richard (which are all rejected):
fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the correct mode during setup and when toggling vlan_filtering on a bridge port. (HEAD -> 6.3-rc)
b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and Enable on CPU ports
cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. This will break Multi CPU when added a seperate patch. It will be overwritten by .port_enable and since we are forcing output to a port via the Special Tag this is not needed.
and now it seems working and is clear ;)
root@bpi-r2:~# ip l show wan
5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff
iperf3
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver
iperf3 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
how do you deal with these patches? do you include them into your mt7530 fixes series? they (and vladimirs preferred cpu-port) need to be applied before these DTS-changes
regards Frank
On 12.04.2023 19:53, Frank Wunderlich wrote: > Hi > >> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr >> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >>> thanks, it changes the master when i upgrade iproute to 6.1 (from debian bullseye-backports), but i cannot do any traffic on it after switching to gmac1... >>> >>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 >>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >>> inet 192.168.0.11/24 scope global wan >>> valid_lft forever preferred_lft forever >>> >>> see no p5-TX/gmac-rx > >> Did you apply the vlan and flooding fix patches from Richard? > > have now applied all patches i've found from richard (which are all rejected): > > fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the correct mode during setup and when toggling vlan_filtering on a bridge port. (HEAD -> 6.3-rc) > b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and Enable on CPU ports > cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. This will break Multi CPU when added a seperate patch. It will be overwritten by .port_enable and since we are forcing output to a port via the Special Tag this is not needed. > > and now it seems working and is clear ;) > > root@bpi-r2:~# ip l show wan > 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 > link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff > > iperf3 > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender > [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver > > > iperf3 -R > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender > [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver > > > how do you deal with these patches? do you include them into your mt7530 fixes series? they (and vladimirs preferred cpu-port) need to be applied before these DTS-changes Dealing with this is the last step on my tasklist. Take a look: https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a Arınç
On 12/04/2023 19:06, Arınç ÜNAL wrote: > On 12.04.2023 19:53, Frank Wunderlich wrote: >> Hi >> >>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr >>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >>>> thanks, it changes the master when i upgrade iproute to 6.1 (from debian >>>> bullseye-backports), but i cannot do any traffic on it after switching to >>>> gmac1... >>>> >>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state >>>> UP group default qlen 1000 >>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >>>> inet 192.168.0.11/24 scope global wan >>>> valid_lft forever preferred_lft forever >>>> >>>> see no p5-TX/gmac-rx >> >>> Did you apply the vlan and flooding fix patches from Richard? >> >> have now applied all patches i've found from richard (which are all rejected): >> >> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the correct >> mode during setup and when toggling vlan_filtering on a bridge port. (HEAD -> >> 6.3-rc) >> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and >> Enable on CPU ports >> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. This >> will break Multi CPU when added a seperate patch. It will be overwritten by >> .port_enable and since we are forcing output to a port via the Special Tag >> this is not needed. >> >> and now it seems working and is clear ;) >> >> root@bpi-r2:~# ip l show wan >> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP >> mode DEFAULT group default qlen 1000 >> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >> >> iperf3 >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender >> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver >> >> >> iperf3 -R >> [ ID] Interval Transfer Bitrate Retr >> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender >> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver >> >> >> how do you deal with these patches? do you include them into your mt7530 fixes >> series? they (and vladimirs preferred cpu-port) need to be applied before >> these DTS-changes > > Dealing with this is the last step on my tasklist. Take a look: > > https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a > I'm a bit lost here. @frank can this be merged now or are there still oustanding issues. It seems to me that not, but just in case... Regards, Matthias
On 29.05.2023 16:40, Matthias Brugger wrote: > > > On 12/04/2023 19:06, Arınç ÜNAL wrote: >> On 12.04.2023 19:53, Frank Wunderlich wrote: >>> Hi >>> >>>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr >>>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >>>>> thanks, it changes the master when i upgrade iproute to 6.1 (from >>>>> debian bullseye-backports), but i cannot do any traffic on it after >>>>> switching to gmac1... >>>>> >>>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc >>>>> noqueue state UP group default qlen 1000 >>>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >>>>> inet 192.168.0.11/24 scope global wan >>>>> valid_lft forever preferred_lft forever >>>>> >>>>> see no p5-TX/gmac-rx >>> >>>> Did you apply the vlan and flooding fix patches from Richard? >>> >>> have now applied all patches i've found from richard (which are all >>> rejected): >>> >>> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in >>> the correct mode during setup and when toggling vlan_filtering on a >>> bridge port. (HEAD -> 6.3-rc) >>> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User >>> ports and Enable on CPU ports >>> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by >>> default. This will break Multi CPU when added a seperate patch. It >>> will be overwritten by .port_enable and since we are forcing output >>> to a port via the Special Tag this is not needed. >>> >>> and now it seems working and is clear ;) >>> >>> root@bpi-r2:~# ip l show wan >>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue >>> state UP mode DEFAULT group default qlen 1000 >>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >>> >>> iperf3 >>> [ ID] Interval Transfer Bitrate Retr >>> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 >>> sender >>> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec >>> receiver >>> >>> >>> iperf3 -R >>> [ ID] Interval Transfer Bitrate Retr >>> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 >>> sender >>> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec >>> receiver >>> >>> >>> how do you deal with these patches? do you include them into your >>> mt7530 fixes series? they (and vladimirs preferred cpu-port) need to >>> be applied before these DTS-changes >> >> Dealing with this is the last step on my tasklist. Take a look: >> >> https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a >> > > I'm a bit lost here. @frank can this be merged now or are there still > oustanding issues. It seems to me that not, but just in case... I fixed the network connectivity issue on the MT7530 DSA sudriver which was the main problem this patch series would cause. I don't see an issue that should block this series anymore. With the current MT7530 DSA sudriver, port 5 will be the active CPU port instead of 6. I've got a patch series to prefer port 6 instead but in the meantime, this patch series should be good to apply. Arınç
On 03/06/2023 12:48, Arınç ÜNAL wrote: > On 29.05.2023 16:40, Matthias Brugger wrote: >> >> >> On 12/04/2023 19:06, Arınç ÜNAL wrote: >>> On 12.04.2023 19:53, Frank Wunderlich wrote: >>>> Hi >>>> >>>>> Gesendet: Mittwoch, 12. April 2023 um 18:21 Uhr >>>>> Von: "Arınç ÜNAL" <arinc.unal@arinc9.com> >>>>>> thanks, it changes the master when i upgrade iproute to 6.1 (from debian >>>>>> bullseye-backports), but i cannot do any traffic on it after switching to >>>>>> gmac1... >>>>>> >>>>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue >>>>>> state UP group default qlen 1000 >>>>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >>>>>> inet 192.168.0.11/24 scope global wan >>>>>> valid_lft forever preferred_lft forever >>>>>> >>>>>> see no p5-TX/gmac-rx >>>> >>>>> Did you apply the vlan and flooding fix patches from Richard? >>>> >>>> have now applied all patches i've found from richard (which are all rejected): >>>> >>>> fe4495bb3cc2 2023-02-12 Fix setting up CPU and User ports to be in the >>>> correct mode during setup and when toggling vlan_filtering on a bridge >>>> port. (HEAD -> 6.3-rc) >>>> b0641f3e1a69 2023-02-12 Fix Flooding: Disable by default on User ports and >>>> Enable on CPU ports >>>> cb04b3451524 2023-02-12 Do not add all User ports to the CPU by default. >>>> This will break Multi CPU when added a seperate patch. It will be >>>> overwritten by .port_enable and since we are forcing output to a port via >>>> the Special Tag this is not needed. >>>> >>>> and now it seems working and is clear ;) >>>> >>>> root@bpi-r2:~# ip l show wan >>>> 5: wan@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state >>>> UP mode DEFAULT group default qlen 1000 >>>> link/ether f2:d2:51:56:cd:3d brd ff:ff:ff:ff:ff:ff >>>> >>>> iperf3 >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender >>>> [ 5] 0.00-10.03 sec 1.09 GBytes 936 Mbits/sec receiver >>>> >>>> >>>> iperf3 -R >>>> [ ID] Interval Transfer Bitrate Retr >>>> [ 5] 0.00-10.04 sec 1.09 GBytes 936 Mbits/sec 0 sender >>>> [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver >>>> >>>> >>>> how do you deal with these patches? do you include them into your mt7530 >>>> fixes series? they (and vladimirs preferred cpu-port) need to be applied >>>> before these DTS-changes >>> >>> Dealing with this is the last step on my tasklist. Take a look: >>> >>> https://arinc9.notion.site/mt7530-c-improvements-bbfdc2ceb958484b9627297b88bc6d4a >>> >> >> I'm a bit lost here. @frank can this be merged now or are there still >> oustanding issues. It seems to me that not, but just in case... > > I fixed the network connectivity issue on the MT7530 DSA sudriver which was the > main problem this patch series would cause. I don't see an issue that should > block this series anymore. > > With the current MT7530 DSA sudriver, port 5 will be the active CPU port instead > of 6. I've got a patch series to prefer port 6 instead but in the meantime, this > patch series should be good to apply. > > Arınç Applied now, thanks!
© 2016 - 2024 Red Hat, Inc.