From: Murali Karicheri <redacted>
Date: Jan/17/2020, 22:18:07 (UTC+00:00)

Hi Jose,

On 01/07/2020 04:27 AM, Jose Abreu wrote:

quoted

From: Murali Karicheri <redacted>
Date: Jan/03/2020, 22:24:14
(UTC+00:00)

quoted

So you have one sched entry that specify SetAndHold for all remaining
queues. So this means, queue 0 will never get sent. I guess you also
support SetAndRelease so that a mix of SetAndHold followed by
SetAndRelease can be sent to enable sending from Queue 0. Is that
correct?

Something like
                sched-entry H 02 300000 \ <=== 300 usec tx from Q1
                sched-entry R 01 200000   <=== 300 usec tx from Q0

Just trying to understand how this is being used for real world
application.

This is the command I use:

# tc qdisc add dev $intf handle 100: parent root taprio \
	num_tc 4 \
	map 0 1 2 3 3 3 3 3 3 3 3 3 3 3 3 3 \
	base-time $base \
	cycle-time 1000000 \
	sched-entry R 00 100000 \
	sched-entry H 02 200000 \
	sched-entry H 04 300000 \
	sched-entry H 08 400000 \
	flags 0x2
# sleep 2
# iperf3 -c <ip> -u -b 0 -t 15 &
# sleep 5
# echo "Queue 3: Expected=40%, Queue 0 will now be preempted"
# tperf -i <ethX> -p 3

This will basically preempt Queue 0 and flood Queue 3 with express
traffic.

I see you don't include Q0 in your schedule. Why is that the case?

Why is the entry with zero mask introduced (first entry)? Typo?
I thought it should be like below. No?

 > # tc qdisc add dev $intf handle 100: parent root taprio \
 > 	num_tc 4 \
 > 	map 0 1 2 3 3 3 3 3 3 3 3 3 3 3 3 3 \
 > 	base-time $base \
 > 	cycle-time 1000000 \
 > 	sched-entry R 01 100000 \
 > 	sched-entry H 02 200000 \
 > 	sched-entry H 04 300000 \
 > 	sched-entry H 08 400000 \
 > 	flags 0x2

Based on my understanding, if holdAdvance is t1 and releaseAdvance is
t2, hold is asserted t1 nano second before Q1 slot (during first
entry) begins and release is asserted t2 nano second before the start of
Q0 slot (during fourth entry) so that pre-emptable frame start 
transmission during first entry.

I thought R/H entries are a replacement for zero mask entry that
are introduced in the schedule as a guard band before express queue
slot when frame pre-emption not supported. Is my understanding correct?

So the above make sense?

You are right, my example was an old one, sorry.

This is what I'm currently using:

[...]
cycle-time 1000000 \
sched-entry R 02 200000 \
sched-entry R 04 400000 \
sched-entry H 08 400000 \
[...]

Notice I don't need to set Queue 0 on sched-entry because its always 
preemptable queue.

Then I test it with:
# echo "Queue 0: Exp=60%"
# iperf3 -t 15 -c <ip> -Z -A <cpu> &
# sleep 5
# echo "Queue 3: Exp=40%"
# tperf -i <interface> -p 3 -c <cpu>

This will result in:
- iperf will have 60% of bandwidth because Queue 0-2 have 400 + 200 = 60% 
cycle time
- tperf will have 40% of bandwidth because Queue 3 has 40% cycle time and 
is express Queue

---
Thanks,
Jose Miguel Abreu