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;
> > >
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
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
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
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
> >
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
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
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
From: Eric Dumazet
Date: Fri, 15 Apr 2016 07:58:48 -0700
> Having some hidden qdiscs is the real problem here.
+1
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.
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
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
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
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
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
>
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
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
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
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
>
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:
>
> =
>
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
21 matches
Mail list logo