All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>, Phil Sutter <phil@nwl.cc>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump
Date: Fri, 21 Oct 2016 04:36:57 -0700	[thread overview]
Message-ID: <1477049817.7065.56.camel@edumazet-glaptop3.roam.corp.google.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1610211024400.31629@cbobk.fhfr.pm>

On Fri, 2016-10-21 at 10:45 +0200, Jiri Kosina wrote:
> The original reason [1] for having hidden qdiscs (potential scalability 
> issues in qdisc_match_from_root() with single linked list in case of large 
> amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert 
> qdisc linked list to hashtable").
> 
> This allows us for bringing more clarity and determinism into the dump by 
> making default pfifo qdiscs visible.
> 
> [1] http://lkml.kernel.org/r/1460732328.10638.74.camel@edumazet-glaptop3.roam.corp.google.com
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---

Some of us are dealing with huge HTB hierarchies, so adding default fifo
in the dump will add more data pumped from the kernel.

BwE [1] for instance dumps qdisc/classes every 5 seconds.

I guess we'll need to not pull this patch in our kernels.

This reminds me of an HTB patch to avoid dumping rate estimates for HTB.

I will send it today.
 
[1]
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43838.pdf

  reply	other threads:[~2016-10-21 11:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21  8:45 [PATCH] net: sched: make default fifo qdiscs appear in the dump Jiri Kosina
2016-10-21 11:36 ` Eric Dumazet [this message]
2016-10-21 12:56   ` Jiri Kosina
2016-10-21 13:14     ` Eric Dumazet
2016-10-21 15:03       ` David Miller
2016-10-21 15:45         ` Eric Dumazet
2016-10-21 14:59     ` David Miller
2016-10-21 14:55   ` David Miller
2016-10-21 15:27     ` Eric Dumazet

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=1477049817.7065.56.camel@edumazet-glaptop3.roam.corp.google.com \
    --to=eric.dumazet@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=phil@nwl.cc \
    --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.