Date: Mon, 17 Mar 2014 08:26:55 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r263198 - in head/sys: amd64/conf conf net netinet netinet6 sys Message-ID: <DF7D9B2B-75B4-4BB5-8EDC-715521EEB2B6@FreeBSD.org> In-Reply-To: <20140317075436.GA5864@walton.maths.tcd.ie> References: <201403150057.s2F0vofg081606@svn.freebsd.org> <20140317075436.GA5864@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Mar 2014, at 07:54, David Malone <dwmalone@maths.tcd.ie> wrote: >> (1) Merge a software implementation of the Toeplitz hash specified = in >> RSS implemented by David Malone. This is used to allow suitable >> pcbgroup placement of connections before the first packet is >> received from the NIC. Software hashing is generally avoided, >> however, due to high cost of the hash on general-purpose CPUs. >=20 > I could look at a faster software implementation, but I guess most of > the value is when hashing is done on the NIC. In my benchmarking (a couple of years ago) the software path never = really turned up a lot. If you end up with a flow migrating from an RSS = NIC to a non-RSS NIC, you fall back on the 'reservation' hash table, = using the conventional hash and picking up contention, but you don't end = up doing the software version of Toeplitz per-packet. The only reason we = need a software implementation (currently) is to do an initial placement = of a new outbound flow into the hash table prior to receiving a packet = with the hardware-generated hash on it. For the inbound direction, we = can pick it up from the first packet. (Although, actually, we also need = to do it for inbound flows that come from non-RSS NICs -- or localhost = or such). Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DF7D9B2B-75B4-4BB5-8EDC-715521EEB2B6>