[LARTC] Sharing of qdiscs

[Jonathan Naylor <jonathan.naylor@w3z.co.uk>]

If this question is answered in the FAQ, then I apologise.

I am using the HTB qdisc (with SFQ underneath it) to shape traffic for an ISP. 
It works extremely well, certainly much better than the Linux Bandwidth 
Arbitrator I was using before. However I have a question about setting it up. 
At present I have a set of filters that allocate one IP address per HTB 
shaping rule underneath it in the tree structure. There is a HTB at the top 
of the tree capping the whole lot to the bandwidth of the leased line to the 
Internet.

My current system is similar to this:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 2048kbit burst 10kbit

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.1 
flowid 1:2
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 512kbit burst 10kbit
tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.2 
flowid 1:3
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 512kbit burst 10kbit
tc qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10
.
.
.

My question is, can I share leaf HTBs with the same characteristics between 
multiple filters and get the same effect as having one HTB per IP address. To 
create something like this:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 2048kbit burst 10kbit

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.1 
flowid 1:2
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 10.0.0.2 
flowid 1:2
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 512kbit burst 10kbit
tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10

The important point that I want to ensure is that *each* address gets a 512kb 
bandwidth, and not a single 512kb bandwidth shared between the two (or more) 
of them.

Finally if the above is acceptable, would the following work also. Our 
addresses are very logical, each class B subnet of the 10.x.y.z address space 
represents a different speed class, thefore could I do something like:

tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 2048kbit burst 10kbit

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 
10.0.0.0/16 flowid 1:2
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 512kbit burst 10kbit
tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 
10.1.0.0/16 flowid 1:3
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 256kbit burst 10kbit
tc qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10
.
.
.

I have been reading the section on using hashing tables to manage large 
tables, but we are well short of needing it so far, and the above if it were 
to work is a much cleaner configuration AFAICS.

Jonathan

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/