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

From: Jiri Kosina
Date: Tue Jun 28 2016 - 11:19:25 EST


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 behavior restored. At minimal
> > consistency.
>
>
> 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 than usability for
> some users occasionally playing with tc.

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
automatically used as a queue. If another qdisc is
attached, it preempts the default pfifo_fast, which automatically
returns to function when an existing qdisc is detached.

In this sense this qdisc is magic, and unlike other qdiscs.
==========

--
Jiri Kosina
SUSE Labs