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

Groups > linux.kernel > #1433056 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Deleting child qdisc doesn't reset parent to default qdisc? Jiri Kosina <jikos@kernel.org> - 2016-06-28 17:20 +0200
    Re: Deleting child qdisc doesn't reset parent to default qdisc? Cong Wang <xiyou.wangcong@gmail.com> - 2016-06-28 19:30 +0200
      Re: Deleting child qdisc doesn't reset parent to default qdisc? Jiri Kosina <jikos@kernel.org> - 2016-06-28 19:40 +0200

#1433056 — 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 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

[toc] | [next] | [standalone]

#1433161

On Tue, Jun 28, 2016 at 8:19 AM, Jiri Kosina <jikos@kernel.org> 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
>         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.
> ==========

It is out of date, now default qdisc can be set to any other qdisc
via /proc. Also, probably due to historical reasons, we don't have
a unified default default qdisc, some uses bfifo, some uses pfifo,
we may break some existing script if we change that.

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

#1433171

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
> >         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.
> > ==========
> 
> It is out of date, now default qdisc can be set to any other qdisc
> via /proc. Also, probably due to historical reasons, we don't have
> a unified default default qdisc, some uses bfifo, some uses pfifo,
> we may break some existing script if we change that.

While I do understand that reasoning, I'd argue that unpredictable and 
unexpected behavior of TBF causing systems with non-working networking is 
much more likely than any userspace having hard dependency on the fact 
that default (*) qdisc for TBF is noop.

(*) where 'default upon creation' != 'default when reset'

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web