lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 20 Jan 2020 09:18:24 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Murali Karicheri <m-karicheri2@...com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Joao Pinto <Joao.Pinto@...opsys.com>,
        David Ahern <dsahern@...il.com>
Subject: RE: [PATCH iproute2-next] taprio: Add support for the SetAndHold and
 SetAndRelease commands

From: Murali Karicheri <m-karicheri2@...com>
Date: Jan/17/2020, 22:18:07 (UTC+00:00)

> Hi Jose,
> 
> On 01/07/2020 04:27 AM, Jose Abreu wrote:
> > From: Murali Karicheri <m-karicheri2@...com>
> > Date: Jan/03/2020, 22:24:14
> > (UTC+00:00)
> > 
> >> 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

Powered by blists - more mailing lists