netdev - Re: iproute2: tc deletion freezes whole server

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpW-p0+0o8Vks6AOHVt3ndqh+fj+UXGP8wtfi9-Pz-TToQ@mail.gmail.com>
Date:   Thu, 7 May 2020 11:52:42 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Václav Zindulka <vaclav.zindulka@...pnet.cz>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: iproute2: tc deletion freezes whole server

On Tue, May 5, 2020 at 1:46 AM Václav Zindulka
<vaclav.zindulka@...pnet.cz> wrote:
>
> On Mon, May 4, 2020 at 7:46 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > Sorry for the delay. I lost connection to my dev machine, I am trying
> > to setup this on my own laptop.
>
> Sorry to hear that. I will gladly give you access to my testing
> machine where all this nasty stuff happens every time so you can test
> it in place. You can try everything there and have online results. I
> can give you access even to the IPMI console so you can switch the
> kernel during boot easily. I didn't notice this problem until the time
> of deployment. My prior testing machines were with metallic ethernet
> ports only so I didn't know about those problems earlier.

Thanks for the offer! No worries, I setup a testing VM on my laptop.

>
> > On Mon, May 4, 2020 at 10:36 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > >
> > > Regarding to your test result above, I think I saw some difference
> > > on my side, I have no idea why you didn't see any difference. Please
> > > let me collect the data once I setup the test environment shortly today.
>
> I saw some improvement too. It was more than 1.5s faster. Yet it was
> still over 21s. I measured it with perf trace, not with time. I'll try
> it the same way as you did.
>
> >
> > I tried to emulate your test case in my VM, here is the script I use:
> >
> > ====
> > ip li set dev dummy0 up
> > tc qd add dev dummy0 root handle 1: htb default 1
> > for i in `seq 1 1000`
> > do
> >   tc class add dev dummy0 parent 1:0 classid 1:$i htb rate 1mbit ceil 1.5mbit
> >   tc qd add dev dummy0 parent 1:$i fq_codel
> > done
> >
> > time tc qd del dev dummy0 root
> > ====
> >
> > And this is the result:
> >
> >     Before my patch:
> >      real   0m0.488s
> >      user   0m0.000s
> >      sys    0m0.325s
> >
> >     After my patch:
> >      real   0m0.180s
> >      user   0m0.000s
> >      sys    0m0.132s
>
> My results with your test script.
>
> before patch:
> /usr/bin/time -p tc qdisc del dev enp1s0f0 root
> real 1.63
> user 0.00
> sys 1.63
>
> after patch:
> /usr/bin/time -p tc qdisc del dev enp1s0f0 root
> real 1.55
> user 0.00
> sys 1.54
>
> > This is an obvious improvement, so I have no idea why you didn't
> > catch any difference.
>
> We use hfsc instead of htb. I don't know whether it may cause any
> difference. I can provide you with my test scripts if necessary.

Yeah, you can try to replace the htb with hfsc in my script,
I didn't spend time to figure out hfsc parameters.

My point here is, if I can see the difference with merely 1000
tc classes, you should see a bigger difference with hundreds
of thousands classes in your setup. So, I don't know why you
saw a relatively smaller difference.

Thanks.