All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
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>
Subject: Re: [RFC PATCH] net_sched: bulk free tcf_block
Date: Mon, 04 Dec 2017 11:12:31 +0100	[thread overview]
Message-ID: <1512382351.2586.11.camel@redhat.com> (raw)
In-Reply-To: <CAM_iQpU7rXqE0iXQzr5kJx2ab_v6OXmL1drt+VJYJAGoL5dyug@mail.gmail.com>

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

      reply	other threads:[~2017-12-04 10:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 14:25 [RFC PATCH] net_sched: bulk free tcf_block Paolo Abeni
2017-11-29 16:14 ` Alexander Duyck
2017-11-29 18:47   ` Paolo Abeni
2017-12-01  7:14 ` Cong Wang
2017-12-01 11:05   ` Paolo Abeni
2017-12-01 22:07     ` Cong Wang
2017-12-04 10:12       ` Paolo Abeni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1512382351.2586.11.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.