TSN Qbv Test on LS1028ARDB Felix Switch, VLAN tagging issue

[ceroone]

Hello everyone ,

I am trying to perform the TSN Qbv Test on the LS1028ARDB Felix Switch (more especially the tc-taprio alternative). My sender is a NXP board (LS1021ATSN) that is connected to the swp0 interface of the LS1028ARDB and my receiver is a Linux PC, that is connected to the swp1 interface of the LS1028ARDB.

Ping between LS1021ATSN and PC works fine with Qbv inactive.

I run then the following command on the LS1028ARDB to enable Qbv: "tc qdisc replace dev swp1 parent root handle 100 taprio num_tc 8 map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 sched-entry S 02 300000 flags 0x2".

After that, I am supposed to send frames with PCP=2 in VLAN Tag to swp0 from the LS1021ATSN. As I understand it, I need to create a VLAN interface, and map the egress traffic to PCP=2 with the following commands:

# ip link add link eth0 name eth0.0 type vlan id 0 egress-qos-map 0:2 1:2 2:2 3:2 4:2 5:2 6:2 7:2
# ip address add 192.168.1.2 dev eth0.0 (I use a different address from eth0)
# ip link set eth0.0 up

However, ping (with ping <PC-ip> -I eth0.0) doesn't work. Am I doing something wrongly ? Do I need to create a VLAN interface on the PC too ?

Thank you for your help.

ceroone

PS: What does the note below mean exactly ?

"Since the hardware can only use PCP, DSCP or other methods to classify Qos, it cannot map Qos to different hardware queues. mqprio is not implemented in the felix driver, so "map 0 1 2 3 4 5 6 7" in the tc-taprio command is invalid."

[yipingwang]

>tc qdisc replace dev swp0 parent root handle 100 taprio num_tc 8 map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 sched-entry S 02 300000 flags 0x2

You are right, this is to set the Qbv on swp0. But gate list is "sched-entry S 02 300000", which means the lists only include one timeslot. and the '02' means a hex value, which means keep gate open on TC1, which means map to PCP value 1.

>After that, I am supposed to send frames with PCP=2 in VLAN Tag to swp0 from the LS1021ATSN.

You set " ip link add link eth0 name eth0.0 type vlan id 0 egress-qos-map 0:2 1:2 2:2 3:2 4:2 5:2 6:2 7:2" map the ping command queue 0 to PCP value 2. So you should map to PCP value 1 to match the Qbv gate keep open TC.

>Do I need to create a VLAN interface on the PC too ?

Yes, You still need to make a interface with same vlan value. Because the PC side should got frame with vlan added.

I do suggest you to make the vlan interfaces pass ping test before enable the Qbv configuration. You could check the frames counter by command "ethtool -S swp0" to check which queues is passing by your vlan setting.

>"Since the hardware can only use PCP, DSCP or other methods to classify Qos, it cannot map Qos to different hardware queues. mqprio is not implemented in the felix driver, so "map 0 1 2 3 4 5 6 7" in the tc-taprio command is invalid."

I think this means:

First, mqprio is not support. map queues to different traffic class do not supported.  "map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 " is set as the  default mapping(can't changed by different value).  taprio implementation is based on the mqprio, by the mapping part. Setting "map 0 1 2 3 4 5 6 7"  is same as mqprio part. So the "map 0 1 2 3 4 5 6 7" is can't be changed to other value.

[ceroone]

And regarding the ethtool command, it returns this:

ethtool -S swp1 | grep prio
[...]
rx_green_prio_0: 3864
rx_green_prio_1: 0
[...]
tx_green_prio_0: 5773
tx_green_prio_1: 899
[...]

So as I understand it, the problem is with the PC?

[yipingwang · Accepted solution]

It is not a tsn related issue. Your result was showing the frame passed switch.

 Please try to set the PC and ls1021atsn ports with right config.

Create the virtual vlan port by your way, I'll got:

root@IMX8MPEVK-Ubuntu:/# ifconfig eth1.0

eth1.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.3  netmask 255.255.255.255  broadcast 0.0.0.0

        inet6 fe80::204:9fff:fe06:f5f3  prefixlen 64  scopeid 0x20<link>

        ether 00:04:9f:06:f5:f3  txqueuelen 1000  (Ethernet)

        RX packets 276  bytes 14658 (14.6 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1328  bytes 69536 (69.5 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I share my setting:

eth1.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.1.3  netmask 255.255.255.0  broadcast 192.168.1.255

        inet6 fe80::204:9fff:fe06:f5f3  prefixlen 64  scopeid 0x20<link>

        ether 00:04:9f:06:f5:f3  txqueuelen 1000  (Ethernet)

        RX packets 282  bytes 15078 (15.0 KB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1334  bytes 70012 (70.0 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

You need to continue to set netmask and broadcast in the right value for local network.

You could set it by the command:

ifconfig eth1.0 netmask 255.255.255.0

ifconfig boardcast 192.168.1.255

Please set the right netmask and broadcast on both side(PC and ls1021atsn).

Result:

root@LS1028ARDB-Ubuntu:~# tc qdisc replace dev swp2 parent root handle 100 \

> taprio num_tc 8 map 0 1 2 3 4 5 6 7 \

> queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ base-time 0 sched-entry S ff

> 300000 flags 0x2

root@IMX8MPEVK-Ubuntu:/# ping 192.168.1.2 -I eth1.0 PING 192.168.1.2 (192.168.1.2) from 192.168.1.3 eth1.0: 56(84) bytes of data.

64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.757 ms

64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.740 ms

64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.661 ms

64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.679 ms

64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=0.711 ms

64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.690 ms

[ceroone]

I performed again the same procedure and it worked. As you suggested, I took care to indicate this time the broadcast address on both sides. I guess that's where the problem came from.

Before closing the subject I have a few questions to ask.

1) Firstly, from what I understand (and from what you explained in the first message), the Felix switch ports don't support any other traffic classification than the one where the Ethernet frames are put on the queue corresponding directly to their PCP. This qdisc cannot be changed, so it has no effect to execute the "tc qdisc add dev swpX root handle 1: mqprio num_tc 8 map 0 1 2 3 4 5 6 7 hw 1" command, as we did before every test with the ENETC controller. Am I right ?

2) Despite my research, I can't figure out the role of this: "queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7"?  What does the X@Y format correspond to exactly? And when it is omitted (as in the command given in the previous point), what is the default behavior?

3) Why it was not necessary to execute the command "ip link set name br0 type bridge vlan_filtering 1" to perform the Qbv test? What is its role?

4) Finally, a more theoretical question: in the IEEE 802.1Qbv standard, a difference is made between scheduled and non-scheduled traffic. But in the implementation provided by tc-taprio or tsntool-qbvset, does this differentiation actually exist? I feel like all the traffic is scheduled, especially when I look at the way the Time-Aware Scheduler is configured:
cat > qbv5.txt << EOF
t0 11111111b 1000000
t1 00000000b 1000000
EOF

Thank you for your answers.

[ceroone]

Thank you for your answer.

So indeed, it seems that I got a bit confused with the gatemask value in the tc-taprio command.

So now I have the following.

On the LS1021ATSN (sender):

# ip link add link eth0 name eth0.0 type vlan id 0 egress-qos-map 0:1 1:1 2:1 3:1 4:1 5:1 6:1 7:1

# ip address add 192.168.1.2 dev eth0.0 (I use a different address from eth0)

# ip link set eth0.0 up

On the LS1028ARDB (switch):

# tc qdisc replace dev swp0 parent root handle 100 taprio num_tc 8 map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 sched-entry S ff 300000 flags 0x2

(I let all the gates open for the moment)

On the PC (receiver):

$ sudo ip link add link enxyyy name enxyyy.0 type vlan id 0

$ ip address add 192.168.1.4 dev enxyyy.0 (I use a different address from enxyyy)

# ip link set enxyyy.0 up

But here again, I have the same problem when I ping from the LS1021ATSN...

# ping 192.168.1.3 

        -> No VLAN tagged ping, works fine

# ping 192.168.1.4 -I eth0.0

        -> VLAN tagged ping, 100% packet loss