Flow ID, LACP, and igb

[Barney Cordoba]

May I express my glee and astonishment that  you're debating the use of complicated hash functions
for something that's likely to have from 2-8 slots?

Also, the *most* important thing is distribution with realistic data. The goal should be to use the
most trivial function that gives the most balanced distribution with real numbers. Faster is
not better if the result is an unbalanced distribution.

Many of your ports will be 80 and 53, and if you're going through a router your ethernets
may not be very unique, so why even bother to include them? Does getting a good distribution
require that you hash every element individually, or can you get the same distribution with
a faster, simpler way of creating the seed?

There's also the other consideration of packet size. Packets on port 53 are likely to be smaller
than packets on port 80. What you want is equal distribution PER PORT on the ports that will
carry that vast majority of your traffic.

When designing efficient systems, you must not assume that ports and IPs are random, because they're
not. 99% of your load will be on a small number of destination ports and a limited range of source ports.

For a web server application, geting a perfect distribution on the http ports is most crucial.

The hash function in if_lagg.c looks like more of a classroom exercise than a practical implementation. 
If you're going to consider 100M iterations; consider that much of the time is wasted parsing the
packet (again). Why not add a simple sysctl that enables a hash that is created in the ip parser,
when all of the pieces are available without having to re-parse the mbuf?

Or better yet, use the same number of queues on igb as you have LAGG ports, and use the queue id (or RSS)
as the hash, so that your traffic is sync'd between the ethernet adapter queues and the LAGG ports. The card
has already done the work for you.

BC





________________________________
 From: Luigi Rizzo <rizzo at iet.unipi.it>
To: Alan Somers <asomers at freebsd.org> 
Cc: Jack F Vogel <jfv at freebsd.org>; "net at freebsd.org" <net at freebsd.org>; Justin T. Gibbs <gibbs at freebsd.org>; Andre Oppermann <andre at freebsd.org>; T.C. Gubatayao <tgubatayao at barracuda.com> 
Sent: Friday, August 30, 2013 8:04 PM
Subject: Re: Flow ID, LACP, and igb
 

Alan,


On Thu, Aug 29, 2013 at 6:45 PM, Alan Somers <asomers at freebsd.org> wrote:
>
>
> ...
> 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.
>
>
i missed this part of your message, but if i read your code well,
you are running 100M iterations and the numbers below are in seconds,
so if you multiply the numbers by 10 you have the cost per hash in
nanoseconds.

What CPU did you use for your tests ?

Also some of the numbers (FNV and hash32) are suspiciously low.

I believe that the compiler (both of them) have figure out that everything
is constant in these functions, and fnv_32_buf() and hash32_buf() are
inline,
hence they can be optimized to just return a constant.
This does not happen for siphash and jenkins because they are defined
externally.

Can you please re-run the tests in a way that defeats the optimization ?
(e.g. pass a non constant argument to the the hashes so you actually need
to run the code).

cheers
luigi


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
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
_______________________________________________
freebsd-net at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"