From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 20:48:34 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 D07CEAF9; Fri, 17 Jan 2014 20:48: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 9011418CE; Fri, 17 Jan 2014 20:48: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 1W4CVL-000Lri-GC; Fri, 17 Jan 2014 20:42:47 +0400 Message-ID: <52D996FD.6090901@FreeBSD.org> Date: Sat, 18 Jan 2014 00:47:57 +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> <52D84DB0.4050607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 17 Jan 2014 20:48:34 -0000 On 17.01.2014 02:08, Adrian Chadd wrote: > The reason you need to make sure that you end up with hashes for both > src,dst and dst,src being equivalent is to ensure that when you create > an outbound socket, you know up front which path the receive path is > going to come back on. Right now we don't mark new connections - > inbound or outbound - with a flowid until we've received some data on > it. Well, this seems reasonable. However, how do you plan to interact with hardware RSS? For example, currently Intel used to set flowid to cpu number (which can be reasonable in some cases). Afair 82599 advanced RX descriptor contains original value that can be extracted, but we can't change cpu on which packet arrives on (well, we can reprogram indirection table, but..) I can't see any easy way to accomplish custom SW RSS: We can possibly have 1-2-4 ingress HW queues per NIC, ignore driver flowid, re-calculate with modified Toeplitz or similar and push to other ncpu-1 neisr queues. That can work, but requires custom setup (especially for lagg scenarios) and works well for small subset of workloads. It seems also guessing ingress flowid is not very much different between symmetric and asymmetric hashing approaches. > > It's also going to be eventually useful for the pcbgroup stuff, as > vijay has said. > > > -a >