netdev - Re: [PATCH net-next v2 01/17] net: sched: refactor mini_qdisc_pair

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] [day] [month] [year] [list]

Message-ID: <CAM_iQpW1--9iKmTbv1Nu8nC1+5LnFAQUUFvfFov=qfaEAmsrBA@mail.gmail.com>
Date:   Mon, 14 Jan 2019 15:00:37 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Vlad Buslov <vladbu@...lanox.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        David Miller <davem@...emloft.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net-next v2 01/17] net: sched: refactor
 mini_qdisc_pair_swap() to use workqueue

On Mon, Jan 14, 2019 at 11:00 AM Vlad Buslov <vladbu@...lanox.com> wrote:
> Hi Cong,
>
> Any comments regarding benchmark results? Are you okay with
> spinlock-based implementation?
>

Hi,

Sorry for somehow forgetting to response to your last email.

I suggested you to stick to mutex not because it is better than spinlock,
it is because its non-atomic context makes the code better to understand
and easier to review.

If mutex is really slower for you, you have to make a trade-off between
performance and code complexity. And, you can also choose to use
mutex as a starter here, then try to move to spinlock later as a second
step. You don't have to break down RTNL to a small-scope lock and
convert it to a spinlock in one patchset, splitting into two patchsets
makes more sense to me and is much easier for me to review.

And, unlike the RX/TX path, these control paths are not critical,
I don't know if we care about the ~17% difference that much. Not
saying your work is not important, I am saying you are the first one
who wants to improve the performance of these control paths, so I
guess perhaps others don't care much.

BTW, as always, please provide a git branch for your patches,
I definitely don't want to apply 17 patches manually one-by-one
here. :)

Thanks!