On Aug 29, 2013, at 4:21 PM, Alan Somers <asom...@freebsd.org> wrote:
> They're faster, but even with this change, jenkins_hash is still 6 times
> slower than FNV hash.
Actually, I think your test isn't accurately simulating memory access, which
might be skewing the results.
For example, from net/if_lagg.c:
p = hash32_buf(&eh->ether_shost, ETHER_ADDR_LEN, p);
p = hash32_buf(&eh->ether_dhost, ETHER_ADDR_LEN, p);
These two calls can't both be aligned, since ETHER_ADDR_LEN is 6 octets. The
same is true for the other hashed fields in the IP and TCP/UDP headers.
Assuming the mbuf data pointer is aligned, the IP addresses and ports are both
on 2-byte alignments (without VLAN or IP options). In your test, they're all
aligned and in the same cache line.
When I modify the test to simulate an mbuf, lookup3 beats FNV and hash32, and
SipHash is only 2-3 times slower.
> Also, your technique of copying the hashable fields into a separate buffer
> would need modification to work with different types of packet and different
> LAGG_F_HASH[234] flags. Because different packets have different hashable
> fields, struct key would need to be expanded to include the vlan tag, IPV6
> addresses, and IPv6 flowid. lagg_hashmbuf would then have to zero the unused
> fields.
Agreed, but this is relatively simple with a buffer on the stack, and does not
require zeroes or padding. See my modified test, attached.
T.C._______________________________________________
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"
