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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
|