RSTP doesn't actually work on LS1028A

[daoyu]

Hi!

    Nowadays I am testing the STP function on NXP LS1028A TSN switch. It is tested that the STP function of kernel enabled by command brctl stp switch on works as expected.

Then I installed mstpd and mstpctl on the switch and enabled the RSTP according to the following script: (source code from https://github.com/mstpd/mstpd )

#!/bin/bash
# set_rstp.sh
cp /sysdisk/mstp* /usr/bin/
brctl stp switch on
sleep 1
mstpd
sleep 1
mstpctl addbridge switch
sleep 1
mstpctl setforcevers switch rstp

And I configure the network and show the port role by mstpctl showport command:

Then start the flow from 1/1-->1/4, and disconnect the link of swp1 between switch 105 and 106. mstpctl showport tells that swp2 of 105 switched to forwarding state within 1 second. But the flow recovered in about 30 seconds after the link of swp1 disconnected.

The experiment above seems show that RSTP doesn't actually work on LS1028A. If the LS1028A support RSTP or is any error in my configuration?

[yipingwang]

I tested on the Real-time Edge 2.1 version kernel. two ls1028ardb boards links two cables. The Rstp can recover properly when unplug one of the cable .
root@LS1028ARDB-Ubuntu:~# mstpctl showbridge Bridge
Bridge CIST info
enabled yes
bridge id 8.000.CA:6F:D6:DB:68:DC
designated root 8.000.9E:43:DA:D3:1D:42
regional root 8.000.CA:6F:D6:DB:68:DC
root port swp0 (#1)
path cost 20000 internal path cost 0
max age 20 bridge max age 20
forward delay 15 bridge forward delay 15
tx hold count 6 max hops 20
hello time 2 ageing time 300
force protocol version rstp
time since topology change 302
topology change count 1
topology change no
topology change port None
last topology change port swp0

When unplug the swp0 cable, you can see:
64 bytes from 192.168.0.11: icmp_seq=481 ttl=64 time=0.228 ms
64 bytes from 192.168.0.11: icmp_seq=482 ttl=64 time=0.220 ms
64 bytes from 192.168.0.11: icmp_seq=483 ttl=64 time=0.229 ms


64 bytes from 192.168.0.11: icmp_seq=489 ttl=64 time=0.447 ms
64 bytes from 192.168.0.11: icmp_seq=490 ttl=64 time=0.245 ms
64 bytes from 192.168.0.11: icmp_seq=491 ttl=64 time=0.219 ms

There are some frames lost, then recover. total about 6 seconds.

Is that ok for your?
the device kernel driver only to set the port state. The relink state work by the stack layer and application. Should less the work on device driver.

[daoyu]

Thank you yiping!

I reinstalled the mstp application on the devices and tested follow your guidance. Rstp can recover correctly this time.

And I want to know if MSTP is supported on ls1028ardb board. I tried to switch the mode to MSTP, but it failed to mapping different flow with different VID to different tree.

Looking forward to your reply, sincerely.

[yipingwang]

I don't know what the failure issue be you are describing. For linux kernel as I learned, there is stp support, and chip set driver side only support enable or disable is enough. The management all by the user side daemon mstpd. The mstpd is not pre-installed in the release code and did not tested by NXP.

[daoyu]

Indeed for Stp and Rstp, driver side only support enable or disable for a port is enough. But for Mstp, that is not enough. Because a port can be discarding state in one MSTI, but be forwarding state in another MSTI. 

According to section 16.4.14.3.6.2 Multiple Spanning Tree Protocol of QorIQ LS1028A Reference Manual, VLAN_SRC_CHK and VLAN_PORT_MASK fields of VLAN_ACCESS register must be configured differently in different MSTI. This seems not be implemented in the current driver code.

Pls have a check of that.

[yipingwang · Accepted solution]

You are right. I check the driver side and chip description. I confirm we don't have such MSTP support in hardware. But for MSTP, linux kernel side also don't have  such supporting interface. but somebody has start provide the protocol layer code support just yesterday(Feb 16).

See:

https://patchwork.kernel.org/project/netdevbpf/cover/20220216132934.1775649-1-tobias@waldekranz.com/

I think this will take some time we support this part in driver site but not now.

[daoyu]

Thanks for your reply!