Date: Fri, 17 Jan 2014 01:22:56 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: ECMP hash keys? Message-ID: <52D84DB0.4050607@FreeBSD.org> In-Reply-To: <CAJ-VmomP-JaVopS0aneeV82OFtM1Pvb=qKn__mn=ooDXOdgmQw@mail.gmail.com> References: <52D5138B.8050100@fsn.hu> <CA%2BP_MZFQU4%2B05Pk5cZ4NMZujD9vXDrV=mehN7_vz1OZ6r2-f1Q@mail.gmail.com> <52D6525D.50102@FreeBSD.org> <CAJ-VmomP-JaVopS0aneeV82OFtM1Pvb=qKn__mn=ooDXOdgmQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <melifaro@freebsd.org>= 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52D84DB0.4050607>