> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/