[LARTC] ESFQ: request for user input
kaber at trash.net
Sun Jun 24 23:12:40 CEST 2007
Corey Hickey wrote:
> 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:
> 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?
I've CCed netdev. I think merging parts of ESFQ (dynamic depth and
flow number) would make a lot of sense, but I'm intending to submit
an alternative to the ESFQ hashing scheme for 2.6.23:
I have enough trust in ESFQ's stability that I don't think we need
a new qdisc for this and could merge it in SFQ (and the "uses only
1 page" justification isn't true anymore anyway), but I also
wouldn't mind adding a new 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.
> * 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.
> * 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
More information about the LARTC