Date: Thu, 29 Aug 2013 14:40:53 -0700 From: "T.C. Gubatayao" <tgubatayao@barracuda.com> To: Alan Somers <asomers@freebsd.org> Cc: Jack F Vogel <jfv@freebsd.org>, "Justin T. Gibbs" <gibbs@freebsd.org>, Andre Oppermann <andre@freebsd.org>, "net@freebsd.org" <net@freebsd.org> Subject: Re: Flow ID, LACP, and igb Message-ID: <C209B12F-A404-47EC-8225-3F5E4123E05E@barracuda.com> In-Reply-To: <CAOtMX2i5BXqm4_gP67MEmN8szCabp8_QRKfZM0tqFtbEKS31SA@mail.gmail.com> References: <D01A0CB2-B1E3-4F4B-97FA-4C821C0E3FD2@FreeBSD.org> <521BBD21.4070304@freebsd.org> <CAOtMX2jvKGY==t9i-a_8RtMAPH2p1VDj950nMHHouryoz3nbsA@mail.gmail.com> <521EE8DA.3060107@freebsd.org> <BCC2C62D4FE171479E2F1C2593FE508B0BE24383@BN-SCL-MBX03.Cudanet.local> <CAOtMX2h5SGh5eYV50y%2BQB_s367V9iattGU862wwXcONDV%2BTG8g@mail.gmail.com> <0771FC4F-BCDD-4985-A33F-09951806AD99@barracuda.com> <CAOtMX2i5BXqm4_gP67MEmN8szCabp8_QRKfZM0tqFtbEKS31SA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--_002_C209B12FA40447EC82253F5E4123E05Ebarracudacom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Aug 29, 2013, at 4:21 PM, Alan Somers <asomers@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, whic=
h
might be skewing the results.
For example, from net/if_lagg.c:
p =3D hash32_buf(&eh->ether_shost, ETHER_ADDR_LEN, p);
p =3D hash32_buf(&eh->ether_dhost, ETHER_ADDR_LEN, p);
These two calls can't both be aligned, since ETHER_ADDR_LEN is 6 octets. T=
he
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 b=
oth
on 2-byte alignments (without VLAN or IP options). In your test, they're a=
ll =20
aligned and in the same cache line.
When I modify the test to simulate an mbuf, lookup3 beats FNV and hash32, a=
nd
SipHash is only 2-3 times slower.
> Also, your technique of copying the hashable fields into a separate buffe=
r
> would need modification to work with different types of packet and differ=
ent
> LAGG_F_HASH[234] flags. Because different packets have different hashabl=
e
> fields, struct key would need to be expanded to include the vlan tag, IPV=
6
> addresses, and IPv6 flowid. lagg_hashmbuf would then have to zero the un=
used
> 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.=
--_002_C209B12FA40447EC82253F5E4123E05Ebarracudacom_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C209B12F-A404-47EC-8225-3F5E4123E05E>