[LARTC] strict priority

[Alexander Sirotkin]

I'm trying to configure 4 queues with strict priorities based on DSCP.
I tried to following commands, but it seems that the filters I defined
have no effect

tc qdisc add dev eth0 root handle 1: prio bands 4
tc qdisc add dev eth0 parent 1:0 handle 10: pfifo limit 100
tc qdisc add dev eth0 parent 1:1 handle 20: pfifo limit 100
tc qdisc add dev eth0 parent 1:2 handle 30: pfifo limit 100
tc qdisc add dev eth0 parent 1:3 handle 40: pfifo limit 100
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip tos
224 0xff flowid 10:
tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match ip tos
160 0xff flowid 20:
tc filter add dev eth0 parent 1:0 protocol ip prio 3 u32 match ip tos
0 0xff flowid 30:
tc filter add dev eth0 parent 1:0 protocol ip prio 4 u32 match ip tos
32 0xff flowid 40:

Any suggestions ?
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] strict priority

[Alexander Sirotkin]

On 3/28/07, Flechsenhaar, Jon J [EMAIL PROTECTED] wrote:

Alex:

1.
~ tc qdisc add dev eth0 root handle 1: prio bands 4
This command created 4 priority classes 1:1 - 1:4

2. Attach your pfifo qidisc to these so basically not on the 1:0

~ tc qdisc add dev eth0 parent 1:0 handle 10: pfifo limit 100
- should be tc qdisc add dev eth0 parent 1:1 handle 10: pfifo
limit 100
3.
filter traffic to 1:1 - 1:4 NOT ON THE PFIFO qdisc
  so...
... Flowid 1:1 not 10

Hope this helps.


Thanks a lot, it did the trick.
In this configuration, 10: will have the highest priority and 40:
lowest, right ?





Jon Flechsenhaar
Boeing WNW Team
Network Services
(714)-762-1231
202-E7

-Original Message-
From: Alexander Sirotkin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 9:13 AM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] strict priority

I'm trying to configure 4 queues with strict priorities based on DSCP.
I tried to following commands, but it seems that the filters I defined
have no effect

tc qdisc add dev eth0 root handle 1: prio bands 4 tc qdisc add dev eth0
parent 1:0 handle 10: pfifo limit 100 tc qdisc add dev eth0 parent 1:1
handle 20: pfifo limit 100 tc qdisc add dev eth0 parent 1:2 handle 30:
pfifo limit 100 tc qdisc add dev eth0 parent 1:3 handle 40: pfifo limit
100 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip
tos
224 0xff flowid 10:
tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match ip tos
160 0xff flowid 20:
tc filter add dev eth0 parent 1:0 protocol ip prio 3 u32 match ip tos 0
0xff flowid 30:
tc filter add dev eth0 parent 1:0 protocol ip prio 4 u32 match ip tos
32 0xff flowid 40:

Any suggestions ?
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] QoS on receive

[Alexander Sirotkin]

It appears that while Linux has plenty of traffic shaping mechanism on 
transmit, there is nothing on receive side.
While generally it does make sense since transmit is more CPU intensive 
operation, after all receive also
consumes CPU cycles. It is clear that it's best to drop the packet as 
soon as possible, i.e. on receive, if possible -
by the driver itself. It may not be feasible in general case, but I can 
think of a couple of scenarios when it does

make sense.

Any ideas ?
Maybe there is some similar QoS mechanism that I'm not aware of ?

--
Alexander Sirotkin
SW Engineer

Texas Instruments
Broadband Communications Israel (BCIL)
Tel:  +972-9-9706587

Those who do not understand Unix are condemned to reinvent it, poorly.
 -- Henry Spencer 


___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc