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 <ri...@iet.unipi.it> To: Alan Somers <asom...@freebsd.org> Cc: Jack F Vogel <j...@freebsd.org>; "n...@freebsd.org" <n...@freebsd.org>; Justin T. Gibbs <gi...@freebsd.org>; Andre Oppermann <an...@freebsd.org>; T.C. Gubatayao <tgubata...@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 <asom...@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@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@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@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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
