[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWt5B0q5GE_gs-772H+dWUDJxJHG5vy-i6V9SyThyCihg@mail.gmail.com>
Date: Thu, 30 Nov 2017 23:14:48 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC PATCH] net_sched: bulk free tcf_block
On Wed, Nov 29, 2017 at 6:25 AM, Paolo Abeni <pabeni@...hat.com> wrote:
> Currently deleting qdisc with a large number of children and filters
> can take a lot of time:
>
> tc qdisc add dev lo root htb
> for I in `seq 1 1000`; do
> tc class add dev lo parent 1: classid 1:$I htb rate 100kbit
> tc qdisc add dev lo parent 1:$I handle $((I + 1)): htb
> for J in `seq 1 10`; do
> tc filter add dev lo parent $((I + 1)): u32 match ip src 1.1.1.$J
> done
> done
> time tc qdisc del dev root
>
> real 0m54.764s
> user 0m0.023s
> sys 0m0.000s
>
> This is due to the multiple rcu_barrier() calls, one for each tcf_block
> freed, invoked with the rtnl lock held. Most other network related
> tasks will block in this timespan.
Yeah, Eric pointed out this too and I already had an idea to cure
this.
As I already mentioned before, my idea is to refcnt the tcf block
so that we don't need to worry about which is the last. Something
like the attached patch below, note it is PoC _only_, not even
compiled yet. And I am not 100% sure it works either, I will look
deeper tomorrow.
Thanks.
View attachment "tcf-block-refcnt.diff" of type "text/plain" (1874 bytes)
Powered by blists - more mailing lists