From: bert hubert <ahu@ds9a.nl>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages
Date: Sat, 08 Dec 2001 23:08:45 +0000 [thread overview]
Message-ID: <marc-lartc-100785297204538@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100785524509147@msgid-missing>
On Sat, Dec 08, 2001 at 04:56:04PM -0500, jamal wrote:
> > I see that now :-) The right wording appears to be that a Prio is a
> > Work-conserving non-policing shaper.
>
> work conserving is right. non-policing is wrong. Policing is related to
> filters. Shaping is related to schedulers. Prio is a scheduler.
Ok, so 'work-conserving' encodes the fact that it will never delay packets?
> Shaping results in non-work conserving schemes. You can attacha TBF which
> shaping inside a Prio qdisc. That would add non-workconserving-ness to it.
Ok, but pfifo_fast for example will always be work conserving.
> > New wording:
> > Do not confuse this classless simple qdisc with the classful PRIO one!
> > Although they have a lot in common, the PRIO queue can contain different
> > classes, whereas pfifo_fast has hardcoded FIFO bands.
>
> I am not sure if i like the wording: A class is the result of a
> class-ification. Both pfifo_fast and PRIO have builtin class-ifiers.
> Essentially if you treated default prio qdisc and pfifo_fast as black
> boxes, there is _no_ difference. Dont look at the code, think larger
> picture.
Well, I aim for the user. For the user, the big picture may be identical but
the use is quite different. I don't want to get email 'I tried to add a
qdisc to pfifo_fast and it didn't work!'.
New wording:
Do not confuse this classless simple qdisc with the classful PRIO one!
Although they behave similarly, pfifo_fast is classless and you cannot add
other qdiscs to it with the tc command.
I think this covers what you mean and what I want.
> You can have two qdiscs per device, ingress and egress
> Please look at the router model i described earlier. The two hooks are
> very clearly described there.
> Ingress qdisc is work conserving only by design; whereas egress qdiscs
> could be non-work conserving.
True. The ingress qdisc isn't really dequeued.
> Again, look at the definitiions of eg/ingress. You need to have this
> diagram drawn:
>
> http://www.davin.ottawa.on.ca/ols/img9.htm
> in your document.
It's good, will need to asciify it however.
> > other words, it delays certain packets while it doesn't delay others. How
> > would you suggest wording this?
>
> Look at the model draft then lets talk again.
Ok. Rewording of the HOWTO will have to wait on a glossary/definition
section anyhow.
> > > the lo device); they might find that all their packets greater than 2K
> > > being dropped.
> >
> > Sure?
>
> 100% sure. Try a little experiment then look at the code again.
I will, but I bet you 5 euros that I'm right :-) We are talking about the
TBF, aren't we?
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
Trilab The Technology People
Netherlabs BV / Rent-a-Nerd.nl - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
next prev parent reply other threads:[~2001-12-08 23:08 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-08 20:43 [LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages jamal
2001-12-08 21:30 ` bert hubert
2001-12-08 21:56 ` jamal
2001-12-08 23:08 ` bert hubert [this message]
2001-12-08 23:29 ` jamal
2001-12-08 23:30 ` jamal
2001-12-08 23:45 ` Henrik Nordstrom
2001-12-08 23:54 ` bert hubert
2001-12-09 1:19 ` jamal
2001-12-09 1:35 ` bert hubert
2001-12-09 2:11 ` jamal
2001-12-09 2:30 ` jamal
2001-12-09 11:38 ` Henrik Nordstrom
2001-12-09 14:40 ` bert hubert
2001-12-09 14:49 ` jamal
2001-12-09 15:01 ` jamal
2001-12-09 15:49 ` Henrik Nordstrom
2001-12-09 16:45 ` Henrik Nordstrom
2001-12-09 21:41 ` jamal
2001-12-09 22:33 ` Michael T. Babcock
2001-12-09 22:36 ` Michael T. Babcock
2001-12-10 1:12 ` Cédric Rivard
2001-12-10 7:53 ` Don Cohen
2001-12-10 8:38 ` Martin Devera
2001-12-10 8:41 ` Henrik Nordstrom
2001-12-10 9:59 ` Henrik Nordstrom
2001-12-10 11:35 ` Martin Devera
2001-12-10 11:59 ` Martin Devera
2001-12-10 12:00 ` Henrik Nordstrom
2001-12-10 12:14 ` bert hubert
2001-12-10 12:25 ` Henrik Nordstrom
2001-12-10 12:52 ` Martin Devera
2001-12-10 13:29 ` jamal
2001-12-10 13:40 ` Martin Devera
2001-12-10 13:42 ` Jim Fleming
2001-12-10 13:52 ` Michael T. Babcock
2001-12-10 13:54 ` Michael T. Babcock
2001-12-10 13:56 ` Gerry Creager N5JXS
2001-12-10 13:58 ` Michael T. Babcock
2001-12-10 14:02 ` Martin Devera
2001-12-10 14:51 ` Jim Fleming
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=marc-lartc-100785297204538@msgid-missing \
--to=ahu@ds9a.nl \
--cc=lartc@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.