netdev - Re: [net v4 2/3] net: sched: add check tc_skip

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: <CANn89iJVReHeT2y+QAOGh1mJ64PG-8QH_FoL5moY634jJpZVvQ@mail.gmail.com>
Date:   Mon, 6 Dec 2021 18:38:44 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Antoine Tenart <atenart@...nel.org>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Wei Wang <weiwan@...gle.com>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [net v4 2/3] net: sched: add check tc_skip_classify in sch egress

On Mon, Dec 6, 2021 at 6:17 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
>
> On Sat, Dec 4, 2021 at 9:42 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> >
> > On Sat, Dec 4, 2021 at 5:35 AM Daniel Borkmann <daniel@...earbox.net> wrote:
> > >
> > > On 12/2/21 3:47 AM, xiangxia.m.yue@...il.com wrote:
> > > > From: Tonghao Zhang <xiangxia.m.yue@...il.com>
> > > >
> > > > Try to resolve the issues as below:
> > > > * We look up and then check tc_skip_classify flag in net
> > > >    sched layer, even though skb don't want to be classified.
> > > >    That case may consume a lot of cpu cycles.
> > > >
> > > >    Install the rules as below:
> > > >    $ for id in $(seq 1 10000); do
> > > >    $       tc filter add ... egress prio $id ... action mirred egress redirect dev ifb0
> > > >    $ done
> > > >
> > > >    netperf:
> > > >    $ taskset -c 1 netperf -t TCP_RR -H ip -- -r 32,32
> > > >    $ taskset -c 1 netperf -t TCP_STREAM -H ip -- -m 32
> > > >
> > > >    Before: 152.04 tps, 0.58 Mbit/s
> > > >    After:  303.07 tps, 1.51 Mbit/s
> > > >    For TCP_RR, there are 99.3% improvement, TCP_STREAM 160.3%.
> > >
> > > As it was pointed out earlier by Eric in v3, these numbers are moot since noone
> > > is realistically running such a setup in practice with 10k linear rules.
> > Yes. As I said in v1, in production, we use the 5+ prio. With this
> > patch, little improvements, 1.x%
> >
> > This patch also fixes the packets loopback, if we use the bpf_redirect
> > to ifb in egress path.
> Hi Daniel, Eric
> What should I do next？This patch try to fix the bug, and improve the
> performance(~1% in production).
> Should I update the commit message and send v5?


This is adding yet another bit in skb :/

We also have another patch series today adding one bit in skb.
For me, this is really an issue. This should be a last resort.

For example xmit_more is no longer a field in skb.
Why, because most probably this property  does not need to stick to
skb, but the context of execution.

Also this is not clear how stacked devices will be handled
(bonding/team/tunnels)