From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 16:02:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D35FE5C2; Thu, 16 Jan 2014 16:02:40 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE48A1A00; Thu, 16 Jan 2014 16:02:39 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id hr13so669111lab.15 for ; Thu, 16 Jan 2014 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YRJt/CgF1IBqjZpZ6gWkufEVUkRUQdJs8FQD0WC+Wzs=; b=YG610A2G7MvBekfOYFr/rSZu7+cOEo2NMrIxSlg28Tgqac+nkcJFGtZtHJZ7ayRx8M P/+bS0jMbn+DFb5x7yDxOA6WhbQHrb8/GuCGo2+tdVyT9eg7JIefIDDUlKUgT85KlyM+ EDdmbs+WbFihm0mUbXGeWufW7ftW2xp7WuBT1OH3Dxmw53TbaBjp/4+su+ohsPn+/bOx FHJuB58Tc+4uLnLkGboQlcOMPKx8gRzJQ+uW7Ugm3BbrsEO0w07X8zE6qwy9Gte4WRGF biODcnC463fT99vsB9q7chNb6yMANqO9ZvADnLu0SWHrFBjG1SLnpA/9dZrvT1NCNTis nbOg== MIME-Version: 1.0 X-Received: by 10.152.121.73 with SMTP id li9mr1423193lab.47.1389888157771; Thu, 16 Jan 2014 08:02:37 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Thu, 16 Jan 2014 08:02:37 -0800 (PST) In-Reply-To: References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> Date: Thu, 16 Jan 2014 16:02:37 +0000 X-Google-Sender-Auth: ryqwKGMbD5dRQM07zGBvpptK0Ao Message-ID: Subject: Re: ECMP hash keys? From: Nikolay Denev To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "Alexander V. Chernikov" , "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 16:02:40 -0000 On Wed, Jan 15, 2014 at 3:22 PM, 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 for >>> rtalloc_mpath_fib() in ip_output.c : >>> >>> ... >>> #ifdef RADIX_MPATH >>> rtalloc_mpath_fib(ro, >>> ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), >>> 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 my >>> 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. > > 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.) > > What do you think? > > > -a Hi Adrian, Probably a stupid question, but I'm trying to understand more about this, so basically the benefit of using essentially an additive hash function would be that both directions of the same flow/connection would end up for processing on the same core? --Nikolay