Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1505580 > unrolled thread

[PATCH] net: sched: make default fifo qdiscs appear in the dump

Started byJiri Kosina <jikos@kernel.org>
First post2016-10-21 10:50 +0200
Last post2016-10-21 17:30 +0200
Articles 9 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] net: sched: make default fifo qdiscs appear in the dump Jiri Kosina <jikos@kernel.org> - 2016-10-21 10:50 +0200
    Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump Eric Dumazet <eric.dumazet@gmail.com> - 2016-10-21 13:40 +0200
      Re: [PATCH] net: sched: make default fifo qdiscs appear in the  dump Jiri Kosina <jikos@kernel.org> - 2016-10-21 15:00 +0200
        Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump Eric Dumazet <eric.dumazet@gmail.com> - 2016-10-21 15:20 +0200
          Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump David Miller <davem@davemloft.net> - 2016-10-21 17:10 +0200
            Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump Eric Dumazet <eric.dumazet@gmail.com> - 2016-10-21 17:50 +0200
        Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump David Miller <davem@davemloft.net> - 2016-10-21 17:00 +0200
      Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump David Miller <davem@davemloft.net> - 2016-10-21 17:00 +0200
        Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump Eric Dumazet <eric.dumazet@gmail.com> - 2016-10-21 17:30 +0200

#1505580 — [PATCH] net: sched: make default fifo qdiscs appear in the dump

FromJiri Kosina <jikos@kernel.org>
Date2016-10-21 10:50 +0200
Subject[PATCH] net: sched: make default fifo qdiscs appear in the dump
Message-ID<suDGy-37e-31@gated-at.bofh.it>
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>
---

Tested for cbq, htb and tbf.

 net/sched/sch_cbq.c    | 4 ++++
 net/sched/sch_drr.c    | 2 ++
 net/sched/sch_dsmark.c | 1 +
 net/sched/sch_hfsc.c   | 2 ++
 net/sched/sch_htb.c    | 1 +
 net/sched/sch_multiq.c | 1 +
 net/sched/sch_prio.c   | 4 +++-
 net/sched/sch_qfq.c    | 1 +
 net/sched/sch_red.c    | 1 +
 net/sched/sch_sfb.c    | 1 +
 net/sched/sch_tbf.c    | 1 +
 11 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index beb554a..3c85e8d 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1161,6 +1161,8 @@ static int cbq_init(struct Qdisc *sch, struct nlattr *opt)
 	if (!q->link.q)
 		q->link.q = &noop_qdisc;
 
+	qdisc_hash_add(q->link.q);
+
 	q->link.priority = TC_CBQ_MAXPRIO - 1;
 	q->link.priority2 = TC_CBQ_MAXPRIO - 1;
 	q->link.cpriority = TC_CBQ_MAXPRIO - 1;
@@ -1606,6 +1608,8 @@ static void cbq_put(struct Qdisc *sch, unsigned long arg)
 	cl->quantum = cl->allot;
 	cl->weight = cl->R_tab->rate.rate;
 
+	qdisc_hash_add(cl->q);
+
 	sch_tree_lock(sch);
 	cbq_link_class(cl);
 	cl->borrow = cl->tparent;
diff --git a/net/sched/sch_drr.c b/net/sched/sch_drr.c
index 8af5c59..1d33b94 100644
--- a/net/sched/sch_drr.c
+++ b/net/sched/sch_drr.c
@@ -118,6 +118,8 @@ static int drr_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
 	if (cl->qdisc == NULL)
 		cl->qdisc = &noop_qdisc;
 
+	qdisc_hash_add(cl->qdisc);
+
 	if (tca[TCA_RATE]) {
 		err = gen_replace_estimator(&cl->bstats, NULL, &cl->rate_est,
 					    NULL,
diff --git a/net/sched/sch_dsmark.c b/net/sched/sch_dsmark.c
index 1308bbf..d0bffd6 100644
--- a/net/sched/sch_dsmark.c
+++ b/net/sched/sch_dsmark.c
@@ -367,6 +367,7 @@ static int dsmark_init(struct Qdisc *sch, struct nlattr *opt)
 	p->q = qdisc_create_dflt(sch->dev_queue, &pfifo_qdisc_ops, sch->handle);
 	if (p->q == NULL)
 		p->q = &noop_qdisc;
+	qdisc_hash_add(p->q);
 
 	pr_debug("%s: qdisc %p\n", __func__, p->q);
 
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 000f1d3..a75710e 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -1066,6 +1066,7 @@ struct hfsc_sched {
 				      &pfifo_qdisc_ops, classid);
 	if (cl->qdisc == NULL)
 		cl->qdisc = &noop_qdisc;
+	qdisc_hash_add(cl->qdisc);
 	INIT_LIST_HEAD(&cl->children);
 	cl->vt_tree = RB_ROOT;
 	cl->cf_tree = RB_ROOT;
@@ -1425,6 +1426,7 @@ struct hfsc_sched {
 					  sch->handle);
 	if (q->root.qdisc == NULL)
 		q->root.qdisc = &noop_qdisc;
+	qdisc_hash_add(q->root.qdisc);
 	INIT_LIST_HEAD(&q->root.children);
 	q->root.vt_tree = RB_ROOT;
 	q->root.cf_tree = RB_ROOT;
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index c798d0d..421d0a9 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1459,6 +1459,7 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
 		qdisc_class_hash_insert(&q->clhash, &cl->common);
 		if (parent)
 			parent->children++;
+		qdisc_hash_add(cl->un.leaf.q);
 	} else {
 		if (tca[TCA_RATE]) {
 			err = gen_replace_estimator(&cl->bstats, NULL,
diff --git a/net/sched/sch_multiq.c b/net/sched/sch_multiq.c
index 9ffbb02..9266e9c 100644
--- a/net/sched/sch_multiq.c
+++ b/net/sched/sch_multiq.c
@@ -217,6 +217,7 @@ static int multiq_tune(struct Qdisc *sch, struct nlattr *opt)
 				sch_tree_lock(sch);
 				old = q->queues[i];
 				q->queues[i] = child;
+				qdisc_hash_add(child);
 
 				if (old != &noop_qdisc) {
 					qdisc_tree_reduce_backlog(old,
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index 8f57589..604a817 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
@@ -192,8 +192,10 @@ static int prio_tune(struct Qdisc *sch, struct nlattr *opt)
 		qdisc_destroy(child);
 	}
 
-	for (i = oldbands; i < q->bands; i++)
+	for (i = oldbands; i < q->bands; i++) {
 		q->queues[i] = queues[i];
+		qdisc_hash_add(q->queues[i]);
+	}
 
 	sch_tree_unlock(sch);
 	return 0;
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index ca0516e..f29676c 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -494,6 +494,7 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid,
 			goto destroy_class;
 	}
 
+	qdisc_hash_add(cl->qdisc);
 	sch_tree_lock(sch);
 	qdisc_class_hash_insert(&q->clhash, &cl->common);
 	sch_tree_unlock(sch);
diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
index 249b2a1..cad2370 100644
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -191,6 +191,7 @@ static int red_change(struct Qdisc *sch, struct nlattr *opt)
 			return PTR_ERR(child);
 	}
 
+	qdisc_hash_add(child);
 	sch_tree_lock(sch);
 	q->flags = ctl->flags;
 	q->limit = ctl->limit;
diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c
index 20a350b..a0a9829 100644
--- a/net/sched/sch_sfb.c
+++ b/net/sched/sch_sfb.c
@@ -512,6 +512,7 @@ static int sfb_change(struct Qdisc *sch, struct nlattr *opt)
 	if (IS_ERR(child))
 		return PTR_ERR(child);
 
+	qdisc_hash_add(child);
 	sch_tree_lock(sch);
 
 	qdisc_tree_reduce_backlog(q->qdisc, q->qdisc->q.qlen,
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 303355c..7e23392 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -396,6 +396,7 @@ static int tbf_change(struct Qdisc *sch, struct nlattr *opt)
 					  q->qdisc->qstats.backlog);
 		qdisc_destroy(q->qdisc);
 		q->qdisc = child;
+		qdisc_hash_add(child);
 	}
 	q->limit = qopt->limit;
 	if (tb[TCA_TBF_PBURST])
-- 
Jiri Kosina
SUSE Labs

[toc] | [next] | [standalone]


#1505806

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-10-21 13:40 +0200
Message-ID<suGl4-4T9-25@gated-at.bofh.it>
In reply to#1505580
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

[toc] | [prev] | [next] | [standalone]


#1505885 — Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump

FromJiri Kosina <jikos@kernel.org>
Date2016-10-21 15:00 +0200
SubjectRe: [PATCH] net: sched: make default fifo qdiscs appear in the dump
Message-ID<suHAv-5DG-47@gated-at.bofh.it>
In reply to#1505806
On Fri, 21 Oct 2016, Eric Dumazet wrote:

> 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.

Okay, so I probably misunderstood you here:

	https://marc.info/?l=linux-kernel&m=146073234818214&w=2

as I thought that as long as we move towards the hashtable, you wouldn't 
have any issues with this.

I'd really like to unhide the default qdiscs, it makes little sense to be 
inconsistent in this way.

Random shot into darkness -- how about making this a 
CONFIG/sysctl-selectable?

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1505918

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-10-21 15:20 +0200
Message-ID<suHTP-60l-21@gated-at.bofh.it>
In reply to#1505885
On Fri, 2016-10-21 at 14:56 +0200, Jiri Kosina wrote:
> On Fri, 21 Oct 2016, Eric Dumazet wrote:
> 
> > 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.
> 
> Okay, so I probably misunderstood you here:
> 
> 	https://marc.info/?l=linux-kernel&m=146073234818214&w=2
> 
> as I thought that as long as we move towards the hashtable, you wouldn't 
> have any issues with this.
> 
> I'd really like to unhide the default qdiscs, it makes little sense to be 
> inconsistent in this way.
> 
> Random shot into darkness -- how about making this a 
> CONFIG/sysctl-selectable?

Oh sorry for the confusion, I believe your patch is fine.

We could add an netlink attribute later for the users that really do not
want default fifo being dumped, but there is no hurry.

Acked-by: Eric Dumazet <edumazet@google.com>

[toc] | [prev] | [next] | [standalone]


#1506045

FromDavid Miller <davem@davemloft.net>
Date2016-10-21 17:10 +0200
Message-ID<suJCi-7mB-35@gated-at.bofh.it>
In reply to#1505918
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Oct 2016 06:14:23 -0700

> On Fri, 2016-10-21 at 14:56 +0200, Jiri Kosina wrote:
>> On Fri, 21 Oct 2016, Eric Dumazet wrote:
>> 
>> > 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.
>> 
>> Okay, so I probably misunderstood you here:
>> 
>> 	https://marc.info/?l=linux-kernel&m=146073234818214&w=2
>> 
>> as I thought that as long as we move towards the hashtable, you wouldn't 
>> have any issues with this.
>> 
>> I'd really like to unhide the default qdiscs, it makes little sense to be 
>> inconsistent in this way.
>> 
>> Random shot into darkness -- how about making this a 
>> CONFIG/sysctl-selectable?
> 
> Oh sorry for the confusion, I believe your patch is fine.
> 
> We could add an netlink attribute later for the users that really do not
> want default fifo being dumped, but there is no hurry.

If this is changing default behavior we should approach this the other
way around.

Keep behaving the way we do, user asks for new behavior with the attribute.

[toc] | [prev] | [next] | [standalone]


#1506089

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-10-21 17:50 +0200
Message-ID<suKeZ-7AT-13@gated-at.bofh.it>
In reply to#1506045
On Fri, 2016-10-21 at 11:03 -0400, David Miller wrote:

> If this is changing default behavior we should approach this the other
> way around.
> 
> Keep behaving the way we do, user asks for new behavior with the attribute.
SGTM

[toc] | [prev] | [next] | [standalone]


#1506027

FromDavid Miller <davem@davemloft.net>
Date2016-10-21 17:00 +0200
Message-ID<suJsC-73K-5@gated-at.bofh.it>
In reply to#1505885
From: Jiri Kosina <jikos@kernel.org>
Date: Fri, 21 Oct 2016 14:56:33 +0200 (CEST)

> I'd really like to unhide the default qdiscs, it makes little sense to be 
> inconsistent in this way.

Something that's been invisible for such a long time... there is no
way applications need or require this.

If some new ones do, they can ask for it via the netlink request
inside of a new netlink attribute or similar.

That makes everyone happy.

[toc] | [prev] | [next] | [standalone]


#1506030

FromDavid Miller <davem@davemloft.net>
Date2016-10-21 17:00 +0200
Message-ID<suJsC-73K-13@gated-at.bofh.it>
In reply to#1505806
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Oct 2016 04:36:57 -0700

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

Eric, quite frankly, this whole "we won't pull this patch into Google
kernels" threat is getting _REALLY_ _OLD_.

If you have a valid technical argument as to why a change should or
should not be applied, make it.  But don't add all of this unnecessary
information, it's simply irrelevant to the technical discussion and
is just emotionally charged.

Thank you.

[toc] | [prev] | [next] | [standalone]


#1506068

FromEric Dumazet <eric.dumazet@gmail.com>
Date2016-10-21 17:30 +0200
Message-ID<suJVE-7tM-41@gated-at.bofh.it>
In reply to#1506030
On Fri, 2016-10-21 at 10:55 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 21 Oct 2016 04:36:57 -0700
> 
> > I guess we'll need to not pull this patch in our kernels.
> 
> Eric, quite frankly, this whole "we won't pull this patch into Google
> kernels" threat is getting _REALLY_ _OLD_.

I am sorry you felt it was a threat, this was certainly not my intent.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web