From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Abeni <pabeni@redhat.com>
Subject: Re: [RFC PATCH] net_sched: bulk free tcf_block
Date: Mon, 04 Dec 2017 11:12:31 +0100
Message-ID: <1512382351.2586.11.camel@redhat.com>
References: <9b2f686e8a08de829d5be050770d16e93ba5d797.1511965365.git.pabeni@redhat.com>
         <CAM_iQpWt5B0q5GE_gs-772H+dWUDJxJHG5vy-i6V9SyThyCihg@mail.gmail.com>
         <1512126307.3155.26.camel@redhat.com>
         <CAM_iQpU7rXqE0iXQzr5kJx2ab_v6OXmL1drt+VJYJAGoL5dyug@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Jiri Pirko <jiri@resnulli.us>,
        "David S. Miller" <davem@davemloft.net>
To: Cong Wang <xiyou.wangcong@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:54794 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752769AbdLDKMd (ORCPT <rfc822;netdev@vger.kernel.org>);
        Mon, 4 Dec 2017 05:12:33 -0500
In-Reply-To: <CAM_iQpU7rXqE0iXQzr5kJx2ab_v6OXmL1drt+VJYJAGoL5dyug@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Hi,

On Fri, 2017-12-01 at 14:07 -0800, Cong Wang wrote:
> On Fri, Dec 1, 2017 at 3:05 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> > 
> > Thank you for the feedback.
> > 
> > I tested your patch and in the above scenario I measure:
> > 
> > real    0m0.017s
> > user    0m0.000s
> > sys     0m0.017s
> > 
> > so it apparently works well for this case.
> 
> Thanks a lot for testing it! I will test it further. If it goes well I will
> send a formal patch with your Tested-by unless you object it.

I'm in late, but I was fine with the above ;)

> > We could still have a storm of rtnl lock/unlock operations while
> > deleting a large tc tree with lot of filters, and I think we can reduce
> > them with bulk free, evenutally applying it to filters, too.
> > 
> > That will also reduce the pressure on the rtnl lock when e.g. OVS H/W
> > offload pushes a lot of rules/sec.
> > 
> > WDYT?
> > 
> 
> Why this is specific to tc filter? From what you are saying, we need to
> batch all TC operations (qdisc, filter and action) rather than just filter?

Exactly, the idea would be to batch all the delayed works. I started
with blocks, to somewhat tackle the issue seen on qdisc removal.

> In short term, I think batching rtnl lock/unlock is a good optimization,
> so I have no objection. For long term, I think we need to revise RTNL
> lock and probably move it down to each layer, but clearly it requires
> much more work.

Agreed!

Paolo