Open p4pe opened 1 year ago
The issue is not the sched-entries
, they only control if/when each traffic class is allowed to transmit.
The place to look is how each traffic class is assigned. One idea that might make it easier to test is to use mqprio
instead of taprio
, as mqprio
has similar concepts of mapping traffic types to traffic classes and then to queues, but less moving parts.
Something like this might just work (not tested):
tc qdisc replace dev gateway-eth0 parent root handle 100 mqprio \
num_tc 8 \
map 0 1 2 3 4 5 6 7 1 1 1 1 1 1 1 1 \
queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
hw 0
Currently, I am working on a TSN project and I am trying to implement a TSN scenario in a Ubuntu 20.04 VM.
I leverage on tc qdisc command:
And also mangle the iptables to classify the packets based on the dscp field.
From what I have read, with this qdisc command I define:
i) 8 traffic classes ii) map priority 0 to TC0, 1 to TC1 2 to TC2 etc. iii) TC0 is mapped to one TX queue TX-0, TC1 to TX-1, TC2 to TX2 etc.
In the sched-entry part of the command, my goal is to open TC2 and TC5, and TC7 queues for different periods.
To test this I sent ping packets using![Στιγμιότυπο οθόνης_20230110_074819](https://user-images.githubusercontent.com/35313995/211624971-f37df4db-ca13-4513-a380-ed9fdb3987a0.png)
ping -Q 0x40 <IP>
(priority 5) in order to send packets to traffic class 5.It seems that the traffic went to the correct queue.
But when I use![Στιγμιότυπο οθόνης_20230110_075106](https://user-images.githubusercontent.com/35313995/211625560-e659f39a-0421-45a3-8128-7badbffcb14b.png)
ping -Q 0x16 <IP>
(priority 2) the traffic went through the last queueAre the sched-entries right?
Thank you.