Re: [RFC PATCH] net: sched: convert qdisc linked list to hashtable (was Re: Deleting child qdisc doesn't reset parent to default qdisc?)

On Thu, 2016-07-07 at 18:32 +0200, Jiri Kosina wrote: > On Thu, 7 Jul 2016, Eric Dumazet wrote: > > > > @@ -1440,6 +1441,7 @@ static int tc_dump_qdisc_root(struct Qdisc *root, > > > struct sk_buff *skb, > > > { > > > int ret = 0, q_idx = *q_idx_p; > > > struct Qdisc *q; > > > + int b; > > >

Re: [RFC PATCH] net: sched: convert qdisc linked list to hashtable (was Re: Deleting child qdisc doesn't reset parent to default qdisc?)

On Thu, 7 Jul 2016, Eric Dumazet wrote: > > @@ -1440,6 +1441,7 @@ static int tc_dump_qdisc_root(struct Qdisc *root, > > struct sk_buff *skb, > > { > > int ret = 0, q_idx = *q_idx_p; > > struct Qdisc *q; > > + int b; > > > > if (!root) > > return 0; > > @@ -1454,7

Re: [RFC PATCH] net: sched: convert qdisc linked list to hashtable (was Re: Deleting child qdisc doesn't reset parent to default qdisc?)

On Thu, 2016-07-07 at 11:04 +0200, Jiri Kosina wrote: > > > From: Jiri Kosina > Subject: [PATCH] net: sched: convert qdisc linked list to hashtable > > Convert the per-device linked list into a hashtable. The primary motivation > for this change is that currently, we're not

[RFC PATCH] net: sched: convert qdisc linked list to hashtable (was Re: Deleting child qdisc doesn't reset parent to default qdisc?)

On Fri, 15 Apr 2016, Eric Dumazet wrote: > Anyway, we probably need to improve our ability to understand qdisc > hierarchies. Having some hidden qdiscs is the real problem here. > > We need to add some hash table so that qdisc_match_from_root() does not > have to scan hundred of qdiscs. So

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Tue, 28 Jun 2016, Cong Wang wrote: > > BTW, I've started to actually work on fixing this, and I've noticed that > > TBF behavior actually violates what's stated in pfifo_fast manpage: > > > > == > > Whenever an interface is created, the pfifo_fast qdisc is > >

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Tue, Jun 28, 2016 at 8:19 AM, Jiri Kosina wrote: > BTW, I've started to actually work on fixing this, and I've noticed that > TBF behavior actually violates what's stated in pfifo_fast manpage: > > == > Whenever an interface is created, the pfifo_fast qdisc

[RFC PATCH] sch_tbf: avoid silent fallback to noop_qdisc (was Re: Deleting child qdisc doesn't reset parent to default qdisc?)

On Fri, 15 Apr 2016, Eric Dumazet wrote: > Then you need to save the initial qdisc (bfifo for TBF) in a special > place, to make sure the delete operation is guaranteed to succeed. > > Or fail the delete if the bfifo can not be allocated. > > I can tell that determinism if far more interesting

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Fri, 15 Apr 2016, Eric Dumazet wrote: > > TBF is probably a bad example because it started life as a classless > > qdisc. There was only one built-in fifo queue that was shaped. Then > > someone made it classful and changed this behavior. To me it sounds > > reasonable to have the default

Re: Deleting child qdisc doesn't reset parent to default qdisc?

From: Eric Dumazet Date: Fri, 15 Apr 2016 07:58:48 -0700 > Having some hidden qdiscs is the real problem here. +1

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Fri, 2016-04-15 at 08:42 -0400, Jamal Hadi Salim wrote: > On 16-04-14 01:49 PM, Eric Dumazet wrote: > > > And what would be the chosen behavior ? > > > > TBF is probably a bad example because it started life as > a classless qdisc. There was only one built-in fifo queue > that was shaped.

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On 16-04-14 01:49 PM, Eric Dumazet wrote: And what would be the chosen behavior ? TBF is probably a bad example because it started life as a classless qdisc. There was only one built-in fifo queue that was shaped. Then someone made it classful and changed this behavior. To me it sounds

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 2016-04-14 at 18:08 +0200, Jiri Kosina wrote: > On Thu, 14 Apr 2016, Phil Sutter wrote: > > > > > I've came across the behavior where adding a child qdisc and then > > > > deleting > > > > it again makes the networking dysfunctional (I guess that's because all > > > > of > > > > a

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 2016-04-14 at 18:22 +0200, Phil Sutter wrote: > And those being invisible can be overridden using 'tc qd add', right? > AFAIR they're not listed because they don't properly register, so the > system doesn't care to override them. In this case we could change all > classful qdiscs to

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, Apr 14, 2016 at 08:44:40AM -0700, Eric Dumazet wrote: > On Thu, 2016-04-14 at 17:34 +0200, Jiri Kosina wrote: > > On Thu, 14 Apr 2016, Phil Sutter wrote: > > > > > OTOH some qdiscs (CBQ, DRR, DSMARK, HFSC, HTB, QFQ) assign the default > > > one upon deletion instead of noop_qdisc, hence I

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 14 Apr 2016, Phil Sutter wrote: > > > I've came across the behavior where adding a child qdisc and then > > > deleting > > > it again makes the networking dysfunctional (I guess that's because all > > > of > > > a sudden there is absolutely no working qdisc on the device, although >

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 2016-04-14 at 17:34 +0200, Jiri Kosina wrote: > On Thu, 14 Apr 2016, Phil Sutter wrote: > > > OTOH some qdiscs (CBQ, DRR, DSMARK, HFSC, HTB, QFQ) assign the default > > one upon deletion instead of noop_qdisc, hence I would describe > > the situation using the words 'inconsistent' and

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 14 Apr 2016, Phil Sutter wrote: > OTOH some qdiscs (CBQ, DRR, DSMARK, HFSC, HTB, QFQ) assign the default > one upon deletion instead of noop_qdisc, hence I would describe > the situation using the words 'inconsistent' and 'accident' rather than > 'expected'. :) Exactly. I'd again like to

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, Apr 14, 2016 at 08:01:39AM -0700, Eric Dumazet wrote: > On Thu, 2016-04-14 at 16:44 +0200, Jiri Kosina wrote: > > Hi, > > > > I've came across the behavior where adding a child qdisc and then deleting > > it again makes the networking dysfunctional (I guess that's because all of > > a

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 2016-04-14 at 16:44 +0200, Jiri Kosina wrote: > Hi, > > I've came across the behavior where adding a child qdisc and then deleting > it again makes the networking dysfunctional (I guess that's because all of > a sudden there is absolutely no working qdisc on the device, although >

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, 14 Apr 2016, Jiri Kosina wrote: > In a nutshell, is this expected behavior or bug? Just to clarify what seems to suggest to me that this is rather a bug that needs to be fixed (but apparently one that has been there for quite a long time) can be demonstrated by this: > > = >

Deleting child qdisc doesn't reset parent to default qdisc?

Hi, I've came across the behavior where adding a child qdisc and then deleting it again makes the networking dysfunctional (I guess that's because all of a sudden there is absolutely no working qdisc on the device, although there originally was a default one in the parent). In a nutshell, is