On Wed, 6 Jul 2004, jamal wrote:
On Tue, 2004-07-06 at 12:09, Stephen Hemminger wrote:
Your examples made me think about this more. The netfilter seem best suited to things that effect the flow of packets (dropping, reordering, even corrupting), and the qdisc seems best when the timing needs to change.
Some of the attributes you are trying to control need queueing; no doubt the best spot to do queueing is on a qdisc. Delays, and reordering for example are ideal. Rate control as well fits here. There are other qdiscs which have done a really good job at rate control hence my arguement against you doing it - you will either not do a better job at it or if you do a good job you will be replicating what they already did; just stash your qdisc in another qdisc which can do a good rate control job (CBQ, TBF, HFSC, HTB) - we are flexible enough in Linux.
Depending on where you want to do things, netfilter may be a good candidate (example IP protocol) or things that dont need queueing. The examples i gave are more powerful than anything netfilter can do at the moment though with only caveat theres only two "hooks".
The limit match in netfilter is not the same as the rate in the qdisc. The netem scheduler acts as if the link is a slow fixed rate. The netfilter limit is usually targeted to drop packets over the rate which is not the same. Reordering is also hard without going out to a user log or building a custom target.
Not sure what the netfilter limit target is - i suspect its something that limits based on a group of flows. You can still do that with a fwamrk at the qdisc level. Reordering needs a queue. Even the example i gave uses a queue that resides on the dummy device.
So, you have convinced me that loss is unnecessary but not the rate, or delay. If we can figure out how to re-ordering with netfilter then that could go too, which would make it possible to use a layered qdisc again.
I think keep the reordering aspect of it unless it is very complex. The delay is a must. If you can add configurable jitter to it that would be a big bonus. Keep the randomization. Duplication, dropping, bit error injection, and rate control are the ones i didnt see belonging there mostly because they can be done better elsewhere. Again this is just opinion, if you think that theres no complexity in the architecture, by all means keep all those features - my recommendation is to pick a few things that will work well and implement them well.
cheers, jamal
I suggest to keep duplication because: 1. Adds 5-10 lines of code and no complexity 2. It's very easy to use it attached directly to a device.
Thank you.
--- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
