From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756720AbcANSYO (ORCPT ); Thu, 14 Jan 2016 13:24:14 -0500 Received: from mail-pa0-f42.google.com ([209.85.220.42]:36622 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752068AbcANSYM (ORCPT ); Thu, 14 Jan 2016 13:24:12 -0500 Message-ID: <1452795849.1223.112.camel@edumazet-glaptop2.roam.corp.google.com> Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout From: Eric Dumazet To: One Thousand Gnomes Cc: Tom Herbert , Haiyang Zhang , David Miller , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , KY Srinivasan , "devel@linuxdriverproject.org" , "linux-kernel@vger.kernel.org" Date: Thu, 14 Jan 2016 10:24:09 -0800 In-Reply-To: <20160114175304.161ff0af@lxorguk.ukuu.org.uk> References: <1452159189-11473-1-git-send-email-vkuznets@redhat.com> <20160110.172558.367101858392871618.davem@davemloft.net> <20160114175304.161ff0af@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-01-14 at 17:53 +0000, One Thousand Gnomes wrote: > > These results for Toeplitz are not plausible. Given random input you > > cannot expect any hash function to produce such uniform results. I > > suspect either your input data is biased or how your applying the hash > > is. > > > > When I run 64 random IPv4 3-tuples through Toeplitz and Jenkins I get > > something more reasonable: > > IPv4 address patterns are not random. Nothing like it. A long long time > ago we did do a bunch of tuning for network hashes using big porn site > data sets. Random it was not. > I ran my tests with non random IPV4 addresses, as I had 2 hosts, one server, one client. (typical benchmark stuff) The only 'random' part was the ports, so maybe ~20 bits of entropy, considering how we allocate ports during connect() to a given destination to avoid port reuse. > It's probably hard to repeat that exercise now with geo specific routing, > and all the front end caches and redirectors on big sites but I'd > strongly suggest random input is not a good test, and also that you need > to worry more about hash attacks than perfect distributions. Anyway, the exercise is not to find a hash that exactly splits 128 flows into 16 buckets, according to the number of flows per bucket. Maybe only 4 flows are sending at 3Gbits, and others are sending at 100 kbits. There is no way the driver can predict the future. This is why we prefer to select a queue given the cpu sending the packet. This permits a natural shift based on actual load, and is the default on linux (see XPS in Documentation/networking/scaling.txt) Only this driver has a selection based on a flow 'hash'.