netdev - Re: [PATCH] Stochastic Fair Blue queue discipline

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Apr 2008 13:17:53 +0200
From:	Juliusz Chroboczek <Juliusz.Chroboczek@....jussieu.fr>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Andi Kleen <andi@...stfloor.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] Stochastic Fair Blue queue discipline

> - traffic schedulers shouldn't depend on perfect random,
> its more about statistical multiplexing.

Okay, I've been thinking about this, and I'm not quite sure that what
sfq and sfb want is a pseudo-random sequence in the first place.

Sfq and sfb only draw random numbers in order to change hashing
functions periodically, so as not to have an innocent flow stuck
within a hash bucket with a non-reactive flow.  For sfb it doesn't
matter much (collisions in a Bloom filter are so rare as to be almost
nonexistent), but for sfq, it is fairly important.

Now assuming jhash is any good, i.e. that a single bit change in the
input changes all output bits with roughly similar probability (and
I don't know whether it is), it shouldn't matter much what sequence of
u32 we use for the perturbation as long as it doesn't repeat values
too often.  Something as simple as a static counter might actually be
good enough.

So I'd argue that the wise thing is to make sure of is that jhash is
good (in the sense above), and not bother too much with the PRNG.

                                        Juliusz
--
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