Hi,
One of my customer needs per flow rate control, so I write one.
The code I post here is not finished, but it seems to work as expected.
The kernel patch is agains kernel 2.6.11, the iproute2 patch is against
iproute2-2.6.11-050314.
I write the code in a hurry to meet deadline. There are many other things to do ahead for me. The code is written in 2 days (including read other queue's code) and tested for a while to find obvious mistake. Don't be suprised when you find many many bugs.
Wow - I wish I could write that in 2 days :-)
The test scenario is like this
www server <- [ eth0 eth1 ] -> www clients
The attached t.sh is used to generate test rules. Clients download a big ISO file from www server, so flows' rate can be estimated by view progress. However I use wget to test the speed, so the speed is accumulated, not current.
What if the client uses a download accelerator and has 12 connections (I suppose server could limit this - but if client is behind nat you may hurt others - which is what sfq does now AIUI, because it doesn't hash on dst port.)
The problems I know:
1. The rtnetlink related code is quick hack. I am not familiar with rtnetlink, so I look at other queue's code and use the simplest one.
2. perflow queue has no stats code. It will be added later.
3. I don't know what is the dump() method 's purpose, so I didn't write dump() method. I will add it later when I know what it is for and how to write rtnetlink code.
Any feedback is welcome. And test it if you can :)
PS: the code is licensed under GPL. If it is acceptable by upstream, it will be submitted.
Having per flow without the drawbacks of sfq is really cool, but I agree with Patrick about letting htb/hfsc limit. You say in the code -
"You should use HTB or other classful qdisc to enclose this qdisc"
So if you do that (unless you meant should not) then you can't guarentee per flow rate anyway without knowing the number of flows, unless you can set rate so high that max flows x flow rate < htb rate.
I think you can still limit per flow ceil if you use htb/hfsc to ratelimit.
I suppose you are solving a different problem with this than I normally shape for ie. you have loads of bandwidth and I have hardly any.
It still could be something really usefull for me though, as I suspect it wouldn't be too hard to add lots of features/switches which (e)sfq doesn't have like -
Per flow queue length limit - and more choice than just tail drop (I am thinking of me shaping from wrong and of link here - server with BIC tcp is horrible with tail drop - others are not as bad).
For people who use esfq for hundreds of users, you could still do fairness of tcp flows within fairness per user address.
Requeue properly which (e)sfq doesn't.
Andy. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
