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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 24 Jun 2007 23:12:40 +0200
From:	Patrick McHardy <>
To:	Corey Hickey <>
CC:	lartc <>,
	Linux Netdev List <>
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:
> 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.
> ---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
More majordomo info at

Powered by blists - more mailing lists