[LARTC] ESFQ: request for user input

[Corey Hickey]

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