Hello, I haven't been keeping up with sending ESFQ [ANNOUNCE] messages to this list, but I've still been working on the patch. If you're curious about recent changes, take a look at the home page, ChangeLog, and README: http://fatooh.org/esfq-2.6/ http://fatooh.org/esfq-2.6/current/ChangeLog http://fatooh.org/esfq-2.6/current/README Meanwhile, I'm interested in finally getting ESFQ included in the Linux kernel. Before I start sending patches and requesting maintainer review, however, there's one question I want to ask current or potential users of SFQ and ESFQ: Should ESFQ be merged into SFQ or remain as a separate qdisc? Note that I can't promise either is an option, since I haven't queried any maintainers yet; I'd rather have a clear idea of what is more desirable to the users before I propose anything. Of course, if any maintainers read this, I would value their input at this point as well. Here are some advantages and disadvantages of merging ESFQ with SFQ. Please correct me or let me know of any others you think of. ---Advantages--- * There's nothing radically different about ESFQ. A separate sch_esfq.c would duplicate lots of the code in sch_sfq.c. * Current users of SFQ would benefit from the better hashing of using jhash. Other than that, the default parameters of ESFQ are the same as SFQ's hardcoded values, so ESFQ would be a drop-in replacement. * Having two similar-looking similarly-functioning qdiscs could be confusing for new users. ---Disadvantages--- * SFQ has been stable for years; it may be undesirable to make changes that could potentially introduce bugs. * ESFQ is marginally slower than SFQ (although I haven't been able to measure a practical difference; if someone has benchmark tips I'll try them). -Corey _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
