netdev - Re: [Patch net-next] net_sched: add reverse binding for tc class

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: <20170831.114105.1838514102434934968.davem@davemloft.net>
Date:   Thu, 31 Aug 2017 11:41:05 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     xiyou.wangcong@...il.com
Cc:     netdev@...r.kernel.org, jhs@...atatu.com
Subject: Re: [Patch net-next] net_sched: add reverse binding for tc class

From: Cong Wang <xiyou.wangcong@...il.com>
Date: Wed, 30 Aug 2017 14:30:36 -0700

> TC filters when used as classifiers are bound to TC classes.
> However, there is a hidden difference when adding them in different
> orders:
> 
> 1. If we add tc classes before its filters, everything is fine.
>    Logically, the classes exist before we specify their ID's in
>    filters, it is easy to bind them together, just as in the current
>    code base.
> 
> 2. If we add tc filters before the tc classes they bind, we have to
>    do dynamic lookup in fast path. What's worse, this happens all
>    the time not just once, because on fast path tcf_result is passed
>    on stack, there is no way to propagate back to the one in tc filters.
> 
> This hidden difference hurts performance silently if we have many tc
> classes in hierarchy.
> 
> This patch intends to close this gap by doing the reverse binding when
> we create a new class, in this case we can actually search all the
> filters in its parent, match and fixup by classid. And because
> tcf_result is specific to each type of tc filter, we have to introduce
> a new ops for each filter to tell how to bind the class.
> 
> Note, we still can NOT totally get rid of those class lookup in
> ->enqueue() because cgroup and flow filters have no way to determine
> the classid at setup time, they still have to go through dynamic lookup.
> 
> Cc: Jamal Hadi Salim <jhs@...atatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@...il.com>

Applied, thanks.