Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
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/

  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