Flow ID, LACP, and igb

[Alan Somers]

On Thu, Aug 29, 2013 at 1:27 AM, T.C. Gubatayao <tgubatayao at barracuda.com>wrote:

> > No problem with fnv_hash().
>
> Doesn't it have bad mixing?  Good distribution is important since this
> code is
> for load balancing.
>

The poor mixing in FNV hash comes from the 8-bit XOR operation.  But that
provides fine mixing of the last 8 bits, which should be sufficient for
lagg_hash unless people are lagging together > 256 ports.


>
> FNV is also slower compared to most of the newer non-cryptographic hashes,
> certainly on large keys, but even on small ones.  Of course, performance
> will
> vary with the architecture.
>
> > While I agree that it is likely that siphash24() is slower if you could
> afford
> > the time do a test run it would be great to from guess to know.
>
> +1


> You might want to consider lookup3 too, since it's also readily available
> in the
> kernel [1].
>

I pulled all four hash functions out into userland and microbenchmarked
them.  The upshot is that hash32 and fnv_hash are the fastest, jenkins_hash
is slower, and siphash24 is the slowest.  Also, Clang resulted in much
faster code than gcc.

http://people.freebsd.org/~asomers/lagg_hash/

[root at sm4u-4 /usr/home/alans/ctest/lagg_hash]# ./lagg_hash-gcc-4.8
FNV: 0.76
hash32: 1.18
SipHash24: 44.39
Jenkins: 6.20
[root at sm4u-4 /usr/home/alans/ctest/lagg_hash]# ./lagg_hash-gcc-4.2.1
FNV: 0.74
hash32: 1.35
SipHash24: 55.25
Jenkins: 7.37
[root at sm4u-4 /usr/home/alans/ctest/lagg_hash]# ./lagg_hash.clang-3.3
FNV: 0.30
hash32: 0.30
SipHash24: 55.97
Jenkins: 6.45
[root at sm4u-4 /usr/home/alans/ctest/lagg_hash]# ./lagg_hash.clang-3.2
FNV: 0.30
hash32: 0.30
SipHash24: 44.52
Jenkins: 6.48



> T.C.
>
> [1]
> http://svnweb.freebsd.org/base/head/sys/libkern/jenkins_hash.c?view=markup