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]

Date:   Mon, 13 Apr 2020 10:28:52 -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 Sun, Apr 12, 2020 at 1:18 PM Václav Zindulka
<vaclav.zindulka@...pnet.cz> wrote:
>
> On Wed, Apr 8, 2020 at 10:18 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > Hi, Václav
>
> Hello Cong,
>
> > Sorry for the delay.
>
> No problem, I'm actually glad you are diagnosing the problem further.
> I didn't have much time until today and late yesterday to apply
> patches and to test it.
>
> > The problem is actually more complicated than I thought, although it
> > needs more work, below is the first pile of patches I have for you to
> > test:
> >
> > https://github.com/congwang/linux/commits/qdisc_reset
> >
> > It is based on the latest net-next branch. Please let me know the result.
>
> I have applied all the patches in your four commits to my custom 5.4.6
> kernel source. There was no change in the amount of fq_codel_reset
> calls. Tested on ifb, RJ45 and SFP+ interfaces.

It is true my patches do not reduce the number of fq_codel_reset() calls,
they are intended to reduce the CPU time spent in each fq_codel_reset().

Can you measure this? Note, you do not have to add your own printk()
any more, because my patches add a few tracepoints, especially for
qdisc_reset(). So you can obtain the time by checking the timestamps
of these trace events. Of course, you can also use perf trace like you
did before.

Thanks!