LARTC - Nov 2007 - prio qdisc broken?

Hello all,
I might make a fool out of me, but I think the prio qdisc doesn''t work 
as
advertised in any document I could lay my hands on.

The following tests and observations were made with Linux kernel 2.6.20.21.
 This makes it up-to-date in the 2.6.20.x kernel family.

My problem was that the link quality reported by the olsr.org olsrd  degraded
depending on the amount of payload traffic was transferred through an
adhoc/mesh interface. The LQ is calculated from the packet loss of LQ  Hello
packets sent through this interface. To make sure normal traffic  does not
interfere with this value, olsrd sets the TOS field to 0x10  (Minimize-Delay)
by default. In theory this should give olsr traffic the highest  priority on the
link.

Investigating this issue I replaced the default Pfifo_fast with a prio  qdisc
and
attached a pfifo on each of the bands:

    INTERFACE=wifi0
    tc qdisc add dev $INTERFACE root handle 1: prio
    tc qdisc add dev $INTERFACE parent 1:1 handle 10: pfifo
    tc qdisc add dev $INTERFACE parent 1:2 handle 20: pfifo
    tc qdisc add dev $INTERFACE parent 1:3 handle 30: pfifo

Then I used "ping -Q TOSVALUE target" to send packets with different
TOS
values  through the interface. "tcpdump -vvv" confirmed the correct
TOS values
in the  outgoing packets.

With "tc -s qdisc ls dev wifi0" I could observe the effects of the 
different TOS
values. The result: no effect at all! Every single packet  used the band
indicated
by the first value in the priomap (e.g. band 1 by  default, in my case the pfifo
with handle 20:). I can''t square this  observation with the available
documentation.

Looking at the source code, it seems that sched_prio uses the  skb->priority
value to select the outgoing band. According to some documentation  I found,
an application can set this value.

The following is more speculation than an educated guess: Could it be that
skb->priority used to be set according to the TOS field by default and that
this
changed after the implementation of prio?

So, can somebody confirm or deny that the problem I see is real? Is there a fix?

Thanks in advance
  Joerg



      Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s
mit dem neuen Yahoo! Mail. www.yahoo.de/mail

Joerg Pommnitz wrote:
> Hello all,
> I might make a fool out of me, but I think the prio qdisc doesn''t
work  as
> advertised in any document I could lay my hands on.
> 
> The following tests and observations were made with Linux kernel 2.6.20.21.
>  This makes it up-to-date in the 2.6.20.x kernel family.
If it''s kernel version you are unlucky - I just tested with a
2.6.19-rc6
and a 2.6.21.1 and it seems OK.

Echo replies don''t work, and they haven''t on others versions
as well,
but this could be deliberate anti dos plus I am not testing forwarded 
traffic.
> 
> My problem was that the link quality reported by the olsr.org olsrd 
degraded
> depending on the amount of payload traffic was transferred through an
> adhoc/mesh interface. The LQ is calculated from the packet loss of LQ 
Hello
> packets sent through this interface. To make sure normal traffic  does not
> interfere with this value, olsrd sets the TOS field to 0x10 
(Minimize-Delay)
> by default. In theory this should give olsr traffic the highest  priority
on the link.
> 
Even if you fix it I don''t think it will help wireless using just prio.

There are/will be extensions to prio AIUI - multiqueue which if the 
wireless driver supports it, prio bands will map to hardware/link layer 
prio bands on the device.

Andy.