Re :Re: in-driver QoS

----- Original Message ----- 
From: "Vladimir Kondratiev" <redacted>
To: <redacted>; <redacted>
Cc: <redacted>
Sent: Wednesday, June 09, 2004 11:21 AM
Subject: Re: in-driver QoS

quoted

quoted

With respect to the 4 different hardware queue, you should see
them only as an extension of the netdev queues. Basically, you just
have a pipeline between the scheduler and the MAC which is almost a
FIFO, but not exactly a FIFO. Those queues may do packet reordering
between themselves, based on priorities. But at the end of the day
they are only going to send what the scheduler is feeding them, and
every packet the scheduler pass to those queues is eventually sent, so
they are totally slave to the scheduler.

Is it a FIFO or there are several DMA rings involved? If the later:
when do you stop the netdevice (i.e call netif_stop_queue())?

You hit the problem. Due to single queue, I can't provide separate back
pressure for different access categories. What I do now, I do some

internal

buffering and netif_stop_queue() when total number of packets (or bytes)
exceed some threshold. Of course, with watermarks to fight jitter.

Let's consider real example. Some application do FTP transfer, lots of

data.

Simultaneously, voice-over-IP connection invoked. Now question is: how to
assure voice quality? Accordingly to TGe, voice is send either with high
priority, or in TSPEC. If we will send all packets with high priority, we
will hit ourselves. If we can't provide some back pressure for low

priority

traffic, it will block voice packets, since some moment you should
netif_stop_queue().

Ideal would be if I can call netif_stop_queue(id), separately for each id.

Two alternatives that I can think of:
1. Maintain only one queue as Jean suggested
    As a hypothetical example, let max queue length be 100. Given 4 priority
levels (1-4 with 4 being the highest) we can define minimum and maximum
threshold for number of slots for each level.

Level              Min                  Max
 4                    35                    55
 3                    25                    45
 2                    15                    35
 1                    5                      25
At any given time, we have 80 slots reserved in proprotion to the priority
and a free pool of 20 slots to support whaichever level is experiencing high
volume.

ofcourse this scheme invalidates the assumption:

Most likely, the FIFOs will share the same memory pool on the
card, so when a FIFO is full, most likely the other FIFOs will be full
or close to it.

2. If all traffic is from a single level, dedicate entire queue to it ... If
there are multiple levels, decide ration the slots ...
If levels 4 and 3 are co-existing, for every 5 packets of level 4, we send 3
packets of level 3 or something like that ... As soon as a new level traffic
begins, the appropriate ratio of slots in the queue are reserved for it ...
They may be full, in that case we can wait for them to empty (150Mbps) or we
can drop some of them and notify failure to higher layers.

Regards
Pragati