From: jamal <hadi@cyberus.ca>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: CBQ and all other qdiscs now REALLY completely documented
Date: Sun, 09 Dec 2001 01:14:10 +0000 [thread overview]
Message-ID: <marc-lartc-100786166720427@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100784252315091@msgid-missing>
On Sun, 9 Dec 2001, bert hubert wrote:
> On Sat, Dec 08, 2001 at 02:20:20PM -0500, jamal wrote:
>
> > Linux remaps packets incoming with different values to some internal
> > value; the colum "mapped to" shows the internal mapping
> >
> > 8value(hex) TOS(dec) mapped to(dec)
> > ----------------------------------
> > 0x0 0 0
> > 1 7
> > 2 0
> > 3 0
> > 4 2
> > 5 2
> > 6 2
> > 7 2
> > 0x10 8 6
> > 9 6
> > 10 6
> > 11 6
> > 12 2
> > 13 2
> > 14 2
> > 15 2
>
> I find this tos2prio table in the kernel (2.5.x), which is somewhat
> different than your table:
>
> 0 TC_PRIO_BESTEFFORT, 0
> 1 TC_PRIO_(FILLER), 1
> 2 TC_PRIO_BESTEFFORT, 0
> 3 TC_PRIO_(BESTEFFORT), 0
> 4 TC_PRIO_BULK, 2
> 5 TC_PRIO_(BULK), 2
> 6 TC_PRIO_BULK, 2
> 7 TC_PRIO_(BULK), 2
> 8 TC_PRIO_INTERACTIVE, 6
> 9 TC_PRIO_(INTERACTIVE), 6
> 10 TC_PRIO_INTERACTIVE, 6
> 11 TC_PRIO_(INTERACTIVE), 6
> 12 TC_PRIO_INTERACTIVE_BULK, 4
> 13 TC_PRIO_(INTERACTIVE_BULK), 4
> 14 TC_PRIO_INTERACTIVE_BULK, 4
> 15 TC_PRIO_(INTERACTIVE_BULK) 4
>
>
> > Fill in the "8value(hex)" column gaps using the bitmap from RFC1349 for
> > the 8 bits; These are the values ou would see with tcpdump -vvv
> > I filled the two easiest ones i could compute in my head.
> >
> > Second step:
> >
> > Take the default priority map:
> > 1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
> > This applies for both default prio and the 3-band FIFO queue.
> > Note the queue map fitted on the last column
> >
> > 8 but value TOS mapped to queue map
> > ---------------------------------------------
> > 0x0 0 0 1
> > 1 7 2
> > 2 0 2
> > 3 0 2
> > 4 2 1
> > 5 2 2
> > 6 2 0
> > 7 2 0
> > 0x10 8 6 1
> > 9 6 1
> > 10 6 1
> > 11 6 1
> > 12 2 1
> > 13 2 1
> > 14 2 1
> > 15 2 1
>
> I've changed this table to:
> TOS Bits Means Linux Priority Band
> ------------------------------------------------------------
> 0x0 0 Normal Service 0 Best Effort 1
> 0x2 1 Minimize Monetary Cost 1 Filler 2
> 0x4 2 Maximize Reliability 0 Best Effort 1
> 0x6 3 mmc+mr 0 Best Effort 1
> 0x8 4 Maximize Throughput 2 Bulk 2
> 0xa 5 mmc+mt 2 Bulk 2
> 0xc 6 mr+mt 2 Bulk 2
> 0xe 7 mmc+mr+mt 2 Bulk 2
> 0x10 8 Minimize Delay 6 Interactive 0
> 0x12 9 mmc+md 6 Interactive 0
> 0x14 10 mr+md 6 Interactive 0
> 0x16 11 mmc+mr+md 6 Interactive 0
> 0x18 12 mt+md 4 Int. Bulk 1
> 0x1a 13 mmc+mt+md 4 Int. Bulk 1
> 0x1c 14 mr+mt+md 4 Int. Bulk 1
> 0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1
>
Yes, sorry the last 4 are int_bulk (value 4) and not just bulk (2). good
eye. You are still abusing the word TOS. Thats only 4 bits not 8;
Use the terminology from RFC1349 at least.
> http://ds9a.nl/lartc/HOWTO/cvs/2.4routing/output/2.4routing-9.html#ss9.2
>
> Your table appears to imply that a Maximum Reliability, Mininum Delay
> packet, TOS bits=9, gets mapped to band 1, not 0, which would not make
> sense.
>
This is the priomap: 1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
It says 1 is the right value
> Laying it out like this, which does appear how it works, does mean that you
> can specify priorities in the priomap which do not correspond to possible
> TOS values.
>
You cant remap the 3 band scheduler trivially, but you should be able to
replace it with a default prio qdisc get exactly the same behavior and use
whatever map you want (eg your 0 to 1 substitution for TOS 1001)
> Is it possible at all to set skb->priority from userspace without going
> through the tos2prio mapping?
>
SO_PRIORITY socket option is doable; you have to be root.
> CBQ can use the skb->priority to classify:
so do prio and pfifo_fast (as i am sure you are aware)
> /*
> * Step 1. If skb->priority points to one of our classes, use it.
> */
> if (TC_H_MAJ(prio^sch->handle) = 0 &&
> (cl = cbq_class_lookup(q, prio)) != NULL)
> return cl;
>
> But to do this, you would need to be able to set skb->priority to a 32bit
> number:
>
Cant think of a straight way to do this .... Alexey would know,
cheers,
jamal
_______________________________________________
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-09 1:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-08 19:20 [LARTC] Re: CBQ and all other qdiscs now REALLY completely documented jamal
2001-12-09 1:14 ` jamal [this message]
2001-12-09 2:10 ` jamal
2001-12-09 18:14 ` kuznet
2001-12-09 18:18 ` bert hubert
2001-12-09 21:45 ` jamal
2001-12-10 17:04 ` kuznet
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-100786166720427@msgid-missing \
--to=hadi@cyberus.ca \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox