Ls1021atsn Qbv working problem.

[jack04060201]

Hello, I'm doing a Qbv test on LS1021atsn.

Here is my experimental architecture:

PC1----swp3[ Ls1021atsn ]swp2----PC2

My Openil branch and config:

master and nxp_ls1021atsn_defconfig

I assume 2 main TSN traffic going out from PC1 (priority 2 & 3). And in my knowledge, TSN wil maps to TC traffic through Vlan PCP. So I set SO_PRIORITY in my code to and ip link add link eth0 name eth0.1 type vlan id 1 egress-qos-map 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 to mapping PCP. It will look like this: (wireshark on PC1)

And setting tc on swp2 & swp3:

As result say that all traffic only passes through TC1, Is my setting or perception wrong?

Looking for help from anyone, thanks.

[vladimiroltean]

The child qdisc stats only count packets sent by software on swp3, they don't count autonomously forwarded traffic.

To make sure of the traffic class used, I would completely close the gate and then check if traffic is still being forwarded.

How was the bridge created between swp2 and swp3 on the LS1021A-TSN board? It needs to be VLAN-aware (ip link add br0 type bridge vlan_filtering 1) in order to perform QoS classification based on VLAN PCP.

[jack04060201]

The child qdisc stats only count packets sent by software on swp3, they don't count autonomously forwarded traffic.

To make sure of the traffic class used, I would completely close the gate and then check if traffic is still being forwarded.

How was the bridge created between swp2 and swp3 on the LS1021A-TSN board? It needs to be VLAN-aware (ip link add br0 type bridge vlan_filtering 1) in order to perform QoS classification based on VLAN PCP.

@vladimiroltean Thanks a lot for your reply! I did set ip link add br0 type bridge vlan_filtering 1 I forgot to mention it sorry. and the bridge is created by the compiled image when boot. I seem them working correctly on wireshark now. I misunderstood what the qdisc stats instruction does.

But if I still have some doubts. I saw your reply in this thread when I learn about the work of TC.

where you used tc filter add dev swp2 egress prio 1 u32 match u16 0x88f7 0xffff at -2 action skbedit priority 1 to match TC traffic. I am trying to use to assign priority to the traffic passing through the ls1021atsn switch like

(command on ls1021atsn)
tc qdisc add dev swp3 clsact
tc filter add dev swp3 ingress prio 1 u32 match u16 0x88f7 0xffff at -2 action skbedit priority 4

but always get TC classifier not found.

After the search. I got the result that CONFIG_NET_CLS_U32 is not set. And test it:

(command on ls1021atsn)
zcat /proc/config.gz | grep NET_CLS_U32
# CONFIG_NET_CLS_U32 is not set

If I want to enable it. where should I set it in openil?

Thank you.

[vladimiroltean]

I saw your reply in this thread when I learn about the work of TC.

You need to be careful when trying various commands found on the Internet. When working with a packet accelerator such as the sja1105, the expectation should be that only a limited subset of tc commands can be offloaded to hardware (according to the hardware capabilities), and in turn see how those capabilities have been exposed to user space. This is probably not what you want, since it would mean that packets are sent to software first, which would incur undesirable latencies.

One thing I can tell you right off the bat is that the sja1105 driver does not offload the tc-u32 classifier, so any such filter matching on the ingress of a switch port will apply only to packets received by software from this port, and not to packets that were autonomously forwarded (and also not to the packets while they were processed in hardware by the switch, even if they later reach the CPU).

The sja1105 will offload certain tc-flower filters (see the code at https://github.com/torvalds/linux/blob/master/drivers/net/dsa/sja1105/sja1105_flower.c and the documentation at https://www.kernel.org/doc/html/latest/networking/dsa/sja1105.html; also cross-check with what is implemented in the older kernel you are using). The tc-flower filters are mapped to Virtual Links, a hardware capability which you need to read more about. Currently it is only possible to reprioritize a frame using tc-flower if you make it match a time-based ingress policing filter (tc-gate) and change its IPV (see the "internal priority" in "man tc-gate"). However, Virtual Links are filters which match on MAC DA, VLAN ID and VLAN PCP, whereas in your case you are trying to match packets based on EtherType. The sja1105 hardware cannot apply packet filters/actions based on EtherType.

However, I see you are trying to match on the EtherType value of 0x88f7 (L2 PTP). So I would like to understand more about what you are trying to do, precisely. Because there is a way in which the sja1105 selects the packet priority of management frames in general (traffic sent to the link-local MAC DA ranges of 01-80-c2-xx-xx-xx or 01-1b-19-xx-xx-xx). The switch always classifies these frames to a value derived from the HOSTPRIO register, and does not look at any other information at all. The sja1105 driver currently hardcodes HOSTPRIO to 7, and since L2 PTP traffic is transmitted to MAC DA values in the link-local multicast range, it means that L2 PTP will always be classified to TC 7. There was an attempt to make HOSTPRIO configurable to a different value, but there wasn't a clear use case for that, and the attempt was finally dropped (please read the comments): https://lore.kernel.org/netdev/20191119073906.GA27697@splinter/T/#m83c1377115266137ef789add25402b0663b59c8e If you have a compelling use case from changing the PTP traffic class from TC 7, please come forth, explain it, and I will try to find a mechanism to make the change possible.

[jack04060201]

Thanks for the reply, what I'm trying is to figure out a way other than using Vlan PCP to match scheduled traffic. Trying to match ptp traffic is just part of the test. There are no plans to make changes to the PTP. I would accept it if match only work on MAC DA, VLAN ID and VLAN PCP.

[jack04060201]

I don't understand the internal priority statement in the tc-gate file. Is it used to map filtered traffic to tc traffic? That mean if I use the following command, will all traffic from 02:42:01:c2:e0:50 pass through the 5000 ns interval?

tc qdisc add dev swp3 root 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 08 5000 \
sched-entry S 04 1000
flags 2

tc qdisc add dev swp3 clsact

tc filter add dev swp3 ingress protocol 802.1Q flower skip_sw \
        dst_mac 02:42:01:c2:e0:50 \
        action gate index 2 \
        base-time 0 \
        sched-entry OPEN 50000000 3 -1 \
        action trap

[vladimiroltean]

Is it used to map filtered traffic to tc traffic?

Yes, it maps the matching traffic to a QoS class within the switch, without altering the VLAN PCP on exit.

will all traffic from 02:42:01:c2:e0:50 pass through the 5000 ns interval?

That exact command no, because of multiple problems. The tc-gate filter also has "action trap", and this will redirect to the CPU any matching traffic rather than forwarding it. Virtual links apply on ingress and always require the destination port to be specified, either through trap, drop or redirect. The second problem is that the virtual link is installed at the ingress of swp3, and the tc-taprio is at the egress of swp3. No packet will match, because no packet ingressing swp3 will also egress swp3. Finally, since the filter has "protocol 802.1Q", it also needs "vlan_id" and "vlan_prio" in order to be accepted by the switch as a valid virtual link.

But otherwise, yes, I expect that something approximating that (but with action mirred egress redirect dev swp4 instead of action trap, and with tc-taprio installed on swp4) should work.

Please remember that the posted tc-taprio schedule does not contain an open gate for TC7, and this will block PTP from working, as explained in the linked thread regarding to HOSTPRIO.

[jack04060201]

@vladimiroltean Thanks for your suggestion, I made the following adjustments to my actual configuration ( PC1 send traffic --ingress -- swp3 -- swp2 --egress -- PC2 recv ).

tc qdisc add dev swp3 root 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 80 2000 \
sched-entry S 08 5000 \
sched-entry S 01 2000 \
flags 2

tc qdisc add dev swp3 clsact

tc filter add dev swp3 ingress protocol 802.1Q flower skip_sw \
    vlan_id 1 \
        dst_mac 00:1b:21:e3:85:62 \
        action gate index 4 \
        base-time 0 \
        sched-entry OPEN 50000000 3 -1 \
        action mirred egress redirect dev swp2

But getting the following errror:

Error: sja1105 Conflict with tc-taprio schedule
We have an error talking to the kernel

I checked the gate index to make sure they don't conflict.

[vladimiroltean]

https://github.com/torvalds/linux/blob/master/drivers/net/dsa/sja1105/sja1105_tas.c#L361

/* Be there 2 port subschedules, each executing an arbitrary number of gate
 * open/close events cyclically.
 * None of those gate events must ever occur at the exact same time, otherwise
 * the switch is known to act in exotically strange ways.
 * However the hardware doesn't bother performing these integrity checks.
 * So here we are with the task of validating whether the new @admin offload
 * has any conflict with the already established TAS configuration in
 * tas_data->offload.  We already know the other ports are in harmony with one
 * another, otherwise we wouldn't have saved them.
 * Each gate event executes periodically, with a period of @cycle_time and a
 * phase given by its cycle's @base_time plus its offset within the cycle
 * (which in turn is given by the length of the events prior to it).
 * There are two aspects to possible collisions:
 * - Collisions within one cycle's (actually the longest cycle's) time frame.
 *   For that, we need to compare the cartesian product of each possible
 *   occurrence of each event within one cycle time.
 * - Collisions in the future. Events may not collide within one cycle time,
 *   but if two port schedules don't have the same periodicity (aka the cycle
 *   times aren't multiples of one another), they surely will some time in the
 *   future (actually they will collide an infinite amount of times).
 */

You do have a clear conflict. At base-time 0, both the sched-entry S 80 2000 from tc-taprio and the sched-entry OPEN 50000000 3 -1 from tc-gate are configured to generate a gate event. This is not possible with the sja1105 hardware implementation.

You need to offset the tc-gate schedule base time compared to the tc-taprio base time with an integer multiple of 200 ns (exactly 200 ns instead of 0 should work). Furthermore, you need to make sure that the length of the tc-gate schedule (50000000 ns) is equal to the length of the tc-taprio schedule (2000 + 5000 + 2000 ns), or a multiple of it.

[jack04060201]

Thanks for the clear explanation. It successfully entered without errors now. but I still need some experimentations to verify it works. You helped me so much on clarification of tc.

Thank you.