From: Florian Westphal <fw@strlen.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org, Miroslav Kratochvil <exa.exa@gmail.com>
Subject: Re: [PATCH] hfsc: ensure class is added to eltree exactly once
Date: Wed, 1 Jun 2016 01:49:55 +0200 [thread overview]
Message-ID: <20160531234955.GB26552@breakpoint.cc> (raw)
In-Reply-To: <1464737614.5939.142.camel@edumazet-glaptop3.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2016-06-01 at 01:00 +0200, Florian Westphal wrote:
> Generally speaking, a non work conserving qdisc could return NULL if it
> decides to drop all packet(s) that were sitting in the queue.
>
> Say we add a 'max sojourn time' on skbs, as yet another anti-bloat
> features, in a Codel variant/extension.
>
> HFSC does check this and eventually complains ( qdisc_warn_nonwc()),
> but all its precise computations are probably wrong.
Right, this is already a problem when using hfsc with silly fq_codel config
(we can end up with underflow on sch->q.qlen, i.e. hfsc
ends up thinking it has 0xffffffff packets in class while fq_codel has 0).
> > > If you want to make HFSC generic, you would need a lot more changes.
> >
> > Could you elaborate?
>
> HFSC is based on packet lengths and realtime/deadline constraints.
>
> With lazy packet lengths (if the attached children qdisc reorder
> packets), this all becomes fuzzy. Which might be OK or not.
>
> We are not helping users by silently making such decisions.
> Maybe they prefer to be warned so that they can fix their setup.
Seems that limits us to pfifo or prio+pfifo only...
> > I'm not interested in e.g. tbf leaves (makes no sense to me), but I
> > think it should play nice with netem, sfq, codel, fq_codel, fq, ...
> >
> > I don't see any problems with fq_codel + hfsc unless I deliberately
> > misconfigure fq_codel (setting extremely low mem limit, e.g. 32kbyte).
>
> That is pure luck, then. I would not be surprised that HTB + nonwc qdisc
> would actually crash in some cases.
Ugh. I think that using codel, sfq, fq_codel etc. should just work
when used with htb or hfsc.
Using tbf and friends should at least not crash kernel (it would
be nice if we could complain and/or reject at config time though).
Thanks for your input, I see this isn't easy to resolve.
prev parent reply other threads:[~2016-05-31 23:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 10:12 [PATCH] hfsc: ensure class is added to eltree exactly once Florian Westphal
2016-05-31 14:55 ` Eric Dumazet
2016-05-31 23:00 ` Florian Westphal
2016-05-31 23:33 ` Eric Dumazet
2016-05-31 23:49 ` Florian Westphal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160531234955.GB26552@breakpoint.cc \
--to=fw@strlen.de \
--cc=eric.dumazet@gmail.com \
--cc=exa.exa@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.