lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 24 Jun 2007 23:12:40 +0200 From: Patrick McHardy <kaber@...sh.net> To: Corey Hickey <bugfood-ml@...ooh.org> CC: lartc <lartc@...lman.ds9a.nl>, Linux Netdev List <netdev@...r.kernel.org> Subject: Re: [LARTC] ESFQ: request for user input Corey Hickey wrote: > 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? 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: http://www.mail-archive.com/netdev@vger.kernel.org/msg39156.html 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. > > ---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). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists