From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: [PATCH net-next 3/6] flow_dissector: Add hash_extra field to flow_keys struct Date: Sun, 1 Mar 2015 20:43:48 +0100 Message-ID: <20150301194348.GB23622@breakpoint.cc> References: <1425093109-1077-1-git-send-email-therbert@google.com> <1425093109-1077-4-git-send-email-therbert@google.com> <1425109054.5130.77.camel@edumazet-glaptop2.roam.corp.google.com> <20150228203119.GA7687@breakpoint.cc> <20150301182425.GA23622@breakpoint.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Westphal , Eric Dumazet , David Miller , Linux Netdev List To: Tom Herbert Return-path: Received: from Chamillionaire.breakpoint.cc ([80.244.247.6]:51873 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751166AbbCATnx (ORCPT ); Sun, 1 Mar 2015 14:43:53 -0500 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Tom Herbert wrote: > We still need hash perturbation for the mapping to a small number of > queues which can be done after retrieving skb_get_hash, but the > probability that two different flows match perfectly in skb_get_hash() > should be 1/2^32-- so are hash collisions really a concern here? I'm not concerned about accidental collisions, how predictable is skb_get_hash()? Is skb_get_hash() guaranteed to e.g. contain L4 information? AFAIK answer to both is "depends on nic/driver", so I feel its better to use software flow dissector.