Qbv basetime test shows "configpending": "ON" until the configured time reached

[hittzt]

Hi experts,

When I test the performace of LSDK20.04 with kernel v4.19 on nxp-ls1028ardb board, I found that, the qbv basetime test shows

   "configpending":        "ON"

after qbvset.

The details as following:

root@localhost:~/tsntest/switch-cases# cat qbv1.txt
t0 11111111b 20000
root@localhost:~/tsntest/switch-cases#

root@localhost:~/tsntest/switch-cases# uname -a
Linux localhost 4.19.90-dirty #2 SMP PREEMPT Tue Jun 16 10:09:28 CST 2020 aarch64 aarch64 aarch64 GNU/Linux
root@localhost:~/tsntest/switch-cases#
root@localhost:~/tsntest/switch-cases# ifconfig
eno2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::a411:b1ff:fe72:6e21 prefixlen 64 scopeid 0x20<link>
ether a6:11:b1:72:6e:21 txqueuelen 1000 (Ethernet)
RX packets 1029 bytes 113046 (113.0 KB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 324 bytes 30474 (30.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 128.224.162.149 netmask 255.255.254.0 broadcast 128.224.163.255
inet6 fe80::8c18:5dff:fe47:33fd prefixlen 64 scopeid 0x20<link>
ether 8e:18:5d:47:33:fd txqueuelen 1000 (Ethernet)
RX packets 98387 bytes 12717293 (12.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 29467 bytes 3857798 (3.8 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 43040 bytes 3055840 (3.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 43040 bytes 3055840 (3.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

switch: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1468
inet 192.168.1.3 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::786d:89ff:febf:f996 prefixlen 64 scopeid 0x20<link>
ether de:11:3d:5e:11:90 txqueuelen 1000 (Ethernet)
RX packets 82 bytes 5792 (5.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 37 bytes 2710 (2.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

swp0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1468
inet6 fe80::dc11:3dff:fe5e:1190 prefixlen 64 scopeid 0x20<link>
ether de:11:3d:5e:11:90 txqueuelen 1000 (Ethernet)
RX packets 13293 bytes 1235394 (1.2 MB)
RX errors 0 dropped 879 overruns 0 frame 0
TX packets 340 bytes 27918 (27.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

swp1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1468
inet6 fe80::dc11:3dff:fe5e:1191 prefixlen 64 scopeid 0x20<link>
ether de:11:3d:5e:11:91 txqueuelen 1000 (Ethernet)
RX packets 54 bytes 4542 (4.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 71 bytes 5866 (5.8 KB)
TX errors 0 dropped 19 overruns 0 carrier 0 collisions 0

swp2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1468
ether de:11:3d:5e:11:92 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

swp3: flags=4099<UP,BROADCAST,MULTICAST> mtu 1468
ether de:11:3d:5e:11:93 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

swp4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1468
inet6 fe80::dc11:3dff:fe5e:1194 prefixlen 64 scopeid 0x20<link>
ether de:11:3d:5e:11:94 txqueuelen 1000 (Ethernet)
RX packets 319 bytes 30820 (30.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1029 bytes 117162 (117.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

root@localhost:~/tsntest/switch-cases#

root@localhost:~/tsntest/switch-cases#
root@localhost:~/tsntest/switch-cases# tsntool ptptool -g -d /dev/ptp1
ptp time: 16000.068940183
./qbv1.txt --basetime 16100.123453ses# tsntool qbvset --device swp1 --entryfile .
echo reply:swp1
root@localhost:~/tsntest/switch-cases# tsntool qbvget --device swp1
echo reply:swp1
tsn: len: 0078 type: 0005 data:
level2: nla->_len: 68 type: 11

listcount = 1
level3: nla->_len: 28 type: 6

entryid = 0
gate = ff
timeperiod = 4e20
gatestate = ff
cycletime = 4e20
basetime = e8cda772a48
configchangetime = ea49a23a648
currenttime = e914dedb074
configpending
listmax = 40
json structure:
{
"oper": {
"listcount": 1,
"list": {
"entryid": 0,
"gate": 255,
"timeperiod": 20000
},
"gatestate": 255,
"cycletime": 20000,
"basetime": 15998123453000
},
"configchangetime": 16100123453000,
"currenttime": 16017240469620,
"configpending": "ON",
"listmax": 64
}
root@localhost:~/tsntest/switch-cases#

root@localhost:~/tsntest/switch-cases# tsntool qbvget --device swp1
echo reply:swp1
tsn: len: 0078 type: 0005 data:
level2: nla->_len: 68 type: 11

listcount = 1
level3: nla->_len: 28 type: 6

entryid = 0
gate = ff
timeperiod = 4e20
gatestate = ff
cycletime = 4e20
basetime = e8cda772a48
configchangetime = ea49a23a648
currenttime = e9df2eca10d
configpending
listmax = 40
json structure:
{
"oper": {
"listcount": 1,
"list": {
"entryid": 0,
"gate": 255,
"timeperiod": 20000
},
"gatestate": 255,
"cycletime": 20000,
"basetime": 15998123453000
},
"configchangetime": 16100123453000,
"currenttime": 16071548248333,
"configpending": "ON",
"listmax": 64
}
root@localhost:~/tsntest/switch-cases#

when the time reached, the configpending disappear as follows:

root@localhost:~/tsntest/switch-cases# tsntool qbvget --device swp1
echo reply:swp1
tsn: len: 0074 type: 0005 data:
level2: nla->_len: 68 type: 11

listcount = 1
level3: nla->_len: 28 type: 6

entryid = 0
gate = ff
timeperiod = 4e20
gatestate = ff
cycletime = 4e20
basetime = ea49a23a648
configchangetime = ea49a23a648
currenttime = ed2d415afeb
listmax = 40
json structure:
{
"oper": {
"listcount": 1,
"list": {
"entryid": 0,
"gate": 255,
"timeperiod": 20000
},
"gatestate": 255,
"cycletime": 20000,
"basetime": 16100123453000
},
"configchangetime": 16100123453000,
"currenttime": 16298664112107,
"listmax": 64
}
root@localhost:~/tsntest/switch-cases#

Does this mean failure of the basetime set? And in my personal opinion, the configpending means the config not set to the hardware yet, so it is invalid on that time. Is this right? or there is something wrong during my test steps?

Thanks,

Zhantao

[yipingwang]

Please refer to the attached TSN switch 802_1 qbv basetime test log.

[hittzt]

Hi Yiping,

I just saw the logs you gave me.

The logs are helpful but did not answer my question about the config-pending status.

I want to know when the config-pending status will show and the impact of the status ?

Because when the config-pending shows in qbv basetime test, it seems the config did not work as it should.

 Thanks,

Zhantao

[yipingwang]

echo "t0 00000000b 20000" > qbv_basetime_cfg_0

tsntool> qbvset --device swp1 --entryfile qbv_basetime_cfg_0

[hittzt]

Hi Yiping,

Thanks for your help.

Sorry for latency respond.

I will check it again.

Thanks,

Zhantao

[hittzt]

Hi Yiping,

Thanks for your reply.

I will check it.

Thanks,

Zhantao