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
On Fri, 2016-10-21 at 10:55 -0400, David Miller wrote:
> From: Eric Dumazet
> 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
From: Eric Dumazet
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
From: Jiri Kosina
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,
From: Eric Dumazet
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
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 secon
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.
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
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 clarit
