Linux Packet Priority

Linux Packet Priority
=====================

Some of the schedulers supplied with Linux Traffic Control allow you to
manipulate a packet based on its priority. At first sight this seems to
mean that you can manipulate a IP packet based on its TOS, but it turns
out it is not so straight forward.

The networking code within Linux handles many protocols besides IP, so
in order to handle the priority of a packet in a generic way it is
translated to a generic “Linux Priority”. The Linux priority of a
packet is a number from 0 to 15, high numbers meaning a higher priority
packet. Not all of the 16 priorities are named in the kernel. Here
are the ones that are named in 2.4.9:

Linux Priority Name Value
———————— —–
TC_PRIO_BESTEFFORT 0
TC_PRIO_FILLER 1
TC_PRIO_BULK 2
TC_PRIO_INTERACTIVE_BULK 4
TC_PRIO_INTERACTIVE 6
TC_PRIO_CONTROL 7
TC_PRIO_MAX 15

When documentation for the Linux’s Traffic Control engine mentions
a packets priority this is the number they are referring to. On
the other hand if the documentation specifically refers to a TOS
or “Type of Service” it probably means bits 4..1 of the TOS field in
the IP packet header.

When a packet passes through the networking code the IP TOS field
is translated to a Linux priority. This table shows how the
translation is done:
IP TOS Priority
IP TOS Name Value Linux Priority Name Value
—————————— ——- ——————- ——–
(Not Set) 0x00 TC_PRIO_BESTEFFORT 0
Cheap 0x02 TC_PRIO_FILLER 1
Reliable 0x04 TC_PRIO_BESTEFFORT 0
Reliable+Cheap 0x06 TC_PRIO_FILLER 1
High Throughput 0x08 TC_PRIO_BULK 2
High Throughput+Cheap 0x0A TC_PRIO_FILLER 1
High Throughput+Reliable 0x0C TC_PRIO_BULK 2
High Throughput+Reliable+Cheap 0x0E TC_PRIO_FILLER 1
Interactive 0x10 TC_PRIO_INTERACTIVE 6
Interactive+Cheap 0x12 TC_PRIO_FILLER 1
Interactive+Reliable 0x14 TC_PRIO_INTERACTIVE 6
Interactive+Reliable+Cheap 0x16 TC_PRIO_FILLER 1
Interactive+High Throughput 0x18 TC_PRIO_INTERACTIVE_BULK 4
Interactive+High Throughput+Cheap 0x1A TC_PRIO_FILLER 1
Reliable+Interactive+High Throughput 0x1C TC_PRIO_INTERACTIVE_BULK 4
Rel+Interactive+High Throughput+Cheap 0x1E TC_PRIO_FILLER 1

Now we can look at how this effects classifying packets based on
their IP TOS value:

– RFC-1349 does not allow more that one TOS bit to be set at one
time. If you assume all packets adhere to RFC-1349 (not a bad
assumption) then the table reduces to 4 lines. The extra
lines are there because rfc791 does allow you to set any
combination of TOS bits.

– But, even if you assume all packets do adhere to RFC-1349,
there is still not a 1 to 1 mapping between IP TOS and Linux
priorities. This is because both IP TOS values 0x00 and
0x04 map to Linux priority 0.

– The inbuilt classifier of most queuing disciplines can classify
packets based on the Linux priority, with out the help of a
filter. In particular CBQ and prio can do this – and it is
quick and convenient. However, because there is not a 1 to 1
mapping of TOS values to Linux priorities you can not use
this inbuilt classifier to classify packets based on their
TOS value. At least you can’t when you want to classify
packets with a TOS value of 0x00 differently to packets with
a TOS value of 0x04.

There is a second way a Linux priority can be encoded, meaning
it can take on another range of values that is not 0..15. The
priority can contain a class handle. (Note that a class handle
has a non-zero value in the most significant 16 bits, so they
are easily distinguishable from normal Unix priorities.) The
classifiers of some queuing disciplines check for this, and if
the packet’s priority contains the handle of one the classes
owned by the queuing discipline it assigns the packet to that
class immediately, by-passing all the normal classification
checks. This feature is not very useful for a number of
reasons, so I suspect Alexey added it to make his testing
easier. I mention it here only for completeness.

About: dato


发表评论

邮箱地址不会被公开。 必填项已用*标注