From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 21:23:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 539949A7; Thu, 16 Jan 2014 21:23:34 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 102DB1A98; Thu, 16 Jan 2014 21:23:34 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W3qZh-000CQ9-8y; Thu, 16 Jan 2014 21:17:49 +0400 Message-ID: <52D84DB0.4050607@FreeBSD.org> Date: Fri, 17 Jan 2014 01:22:56 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ECMP hash keys? References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GFKVBXUUGERNTGMEWDIW" Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 21:23:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GFKVBXUUGERNTGMEWDIW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.01.2014 19:22, Adrian Chadd wrote: > On 15 January 2014 01:18, Alexander V. Chernikov = wrote: >> On 14.01.2014 23:15, Nikolay Denev wrote: >>> >>> Hi, >>> >>> Currently it's implemented using Modulo-N Hash (RFC2991), see >>> radix_mpath.c:rtalloc_mpath_fib() >> >> Yup. I'm going to change this to use flowid. >> >>> >>> And as hash the xor of source and destination IP is supplied, look fo= r >>> rtalloc_mpath_fib() in ip_output.c : >>> >>> ... >>> #ifdef RADIX_MPATH >>> rtalloc_mpath_fib(ro, >>> ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_a= ddr), >>> inp ? inp->inp_inc.inc_fibnum : M_GETFIB= (m)); >>> #else >>> ... >>> >>> I've tried to hack this to use m_pkthdr.flowid if it exists, but in m= y >>> case my network cards were not setting this (vr(4) on soekris) so I >> >> You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get= >> flowid values generated by netisr. >=20 > Hm, this is interesting. I wonder if we should (finally) add in the > toeplitz hash here and then make sure we are hashing the frame based > on the right header contents and direction (so transmit and receive > path frames hash to the same value.) I'm not sure I understand. What workload we are talking about? For pure routing we don't need both ends of TCP session to land on the same CPU core. For doing (transparent?) stateul firewalling - maybe, but that's not the default. Additionally, most (and all 10G) NICs already perform hashing (and toeplitz which is implemented in most? of them does not provide the same hash for forward/reverse packets of given session). We can do re-mark here, but that require us to: * do deferred netisr probably decrementing number of RX rings in every NI= C * improve netist (maybe, add batching and/or lockless queueing) That's definitely not the default, too. For server terminating connections - we can just save flowid of initial connection and that's all. I'm not sure we require hash(src,dst) to be equal to hash(dst,src) So, if you really want hashing function with this additional restriction - than we should add some more sysctls/tunables to netisr to be able to select several different flowid functions for given family (nearly like what is done for TCP CCs). Anyway, we really should add _some_ hashing function for IPv4/IPv6. >=20 > What do you think? >=20 >=20 > -a >=20 ------enig2GFKVBXUUGERNTGMEWDIW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLYTbUACgkQwcJ4iSZ1q2lsfQCePK/bMgOmx/fe1DatUBcv9y93 Ds8AnAoZe2aQ5qorZXjM1yvvzewNV9TC =atI4 -----END PGP SIGNATURE----- ------enig2GFKVBXUUGERNTGMEWDIW--