[LARTC] PRIOMAP, SPLIT, DEFMAP usage info + PRIO, TBF and other bugs

* [LARTC] PRIOMAP, SPLIT, DEFMAP usage info + PRIO, TBF and other bugs
@ 2001-06-30  1:45 ness
  2001-07-02 22:09 ` Nikolai Vladychevski
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: ness @ 2001-06-30  1:45 UTC (permalink / raw)
  To: lartc

[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]

this message was originally send to stafke@iname.com
http://users.belgacom.net/staf/

Currently I'm trying to install all this QoS stuff on my bridge and I have A LOT of problems,
so I very glad to find someone interested in helping others to solve this not trivial problem.

I decided to share that I have found so far with you :)
NOTE: DON'T consider all this correct, it's all just my thoughts. So don't hit me if I'm wrong.

From you TODO list:

1. Unclassified traffic - traffic to which none of the filters has been applyed, so by default it
    will fall to root class. You can use Defmap to assign all this unclassified traffic to other
    class. For example setting Defmap to 0xFFFF will assign all unclassified by other means
    traffic to this class. Split also must be specified else defmap will not work.
    Here is some words from Alex:

"defmaps are intended to make fallback classification
when a packet does not match to any stronger classifier
or no classifiers are configured.

Algorithm is very simple: protocol layer assigns a logical priority
numbered of 0 to 15 to any packet. For forwarded packets it is derived
from tos, for locally originated ones it is controlled by SO_PRIORITY
socket option (or derived from tos too). 

If a class is ready to serve some logical priority,
it has corresponding bit in its defmap.

If packet matches to any classifier, this priority
is ignored. When it does not, cbq searches for class
which is ready to serve corresponding priority level.
That's almost all. Note that, to make cbq working properly,
you should sweep at least all priorities 0..7, otherwise
unclassified packets will fallback to root class,
which is not intended to transmit anything at all.

For IPv4 mapping tos -> priority is established in route.c
by array ip_tos2prio[]. It is not changable from user level for now
and complies to canonical ietf rules. You may change it to
diffserv, if you want.

About "split". Normally, split is root.

You may set split to a node in hierarchy and use some simple
and fast classifier, which understands only limited set of keys
(sort of route), to point to this node.
In this case, only classes with split==this node,
will be matched. It means, that sk->priority and tos
may live in peace with multiagency link sharing
with zero classification cost. Seems, it is
the best my invention for last year 8)"

Ok. So far so good. I still not sleeping :)

2. About this Priomap. This all about this early mentioned "logical priority",
    if we have for example Priomap 0 0 0 0 0  1 1 1 1 1 2 2 2 2 2 2
    then all traffic with any of the 5 high bits set in this "logical priority" will be
    assigned to band 0, if any of the 5 bits set in the middle then this packet
    will be assigned to band 1 and so forth.

Oh, one more notice:
    AS FAR I UNDERSTAND PRIO NOT WORKING AT ALL, OR AT LEAST
    NOT WORKING AS IT MUST WORK.
    First of all it not implement class manipulation functions, so if you just try
    to list PRIO classes (tc class ls dev eth0) this will give you segmentation
    fault :(. The more the better. I far as I understand PRIO qdisc creates classes
    "on fly", so I tryed to filter some packets to this classed. After 2 weaks of
    experements I understand that it don't prioritize packets AT ALL. (I'll be glad
    to hear that I'm wrong...)

    OK some more bugs....

    TBF. If you defined this one as described in README it will not work :(
    At least it's not working on my setup.

    tc qdisc add dev eth1 parent 1:2 tbf rate 64Kbit buffer 5Kb/8 limit 10Kb

    You'll get latency set to something near 5000s :(
    So, to work correctly you must define NOT LIMIT but LATENCY (1000 = 1.2 ms),
    or define BURST and use it with LIMIT, BTW you can't use Kb in burst you must
    use kB :(

    I think this is enough. I'm very interested in you latency testing. How you manage 
    to do some latency changing with CBQ. AFAIK CBQ not intended to PRIORITIZE 
    traffic it only Fair Destribute it in case of congestion.

    Hope for you understanding. And excuse my english. I'm russian too ;)

    Plz share you experience with the comunity!
    Alex where is fixed version? And where is HPFQ support? Where? Aaaa? Gde?
    --
    Ness
    ness@inbox.lv

[-- Attachment #2: Type: text/html, Size: 6784 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread