Martin Devera writes: > I'm not sure. How balanced tree of classes could help you with big number > of filters ? These are unrelated IMHO. When filter determines class number > it is looked using hash table. > If you use u32 with 200 nodes in tree and htb then classification time > will be about 5 steps for each packet... What do you do if you have 100 rules of form: if source ip = ip1 then class1 if source ip = ip2 then class2 if source ip = ip3 then class3 ... I assume you have to try them until one matches or you run out. However, I believe that you now support filters at interior classes. This means that at the top you could do something like if source ip in 10.0.0.0 - 10.0.0.50 then class1 if source ip in 10.0.0.51 - 10.0.0.99 then class2 and then in class1 put filters: if source ip in 10.0.0.0 - 10.0.0.25 then class3 if source ip in 10.0.0.26 - 10.0.0.50 then class3 etc. Then you'd only have to match o(log(n)) filters. > > I don't think this is the problem HTB was meant to solve. > > I think what you really want is the (often suggested/requested) > > modified version of sfq that hashes only on source or destination > > address (depending on whether you use it for the queue going in to or > > Right. I think so too :) HTB can be useful in this way if you want > different parameters (rate,prio) per host .. > But we definitely need the changed sfq. The change is trivial but > I'm too deep in new htb just now :( I can't promise any time soon either. If someone else wants to work on this I'd like to send some (reverse engineered) documentation to include in future sfq - might also help you to make further changes.
