From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757549AbcAJW0D (ORCPT ); Sun, 10 Jan 2016 17:26:03 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:58617 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753259AbcAJW0A (ORCPT ); Sun, 10 Jan 2016 17:26:00 -0500 Date: Sun, 10 Jan 2016 17:25:58 -0500 (EST) Message-Id: <20160110.172558.367101858392871618.davem@davemloft.net> To: vkuznets@redhat.com Cc: netdev@vger.kernel.org, kys@microsoft.com, haiyangz@microsoft.com, devel@linuxdriverproject.org, linux-kernel@vger.kernel.org, eric.dumazet@gmail.com Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout From: David Miller In-Reply-To: <1452159189-11473-1-git-send-email-vkuznets@redhat.com> References: <1452159189-11473-1-git-send-email-vkuznets@redhat.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 10 Jan 2016 14:26:00 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vitaly Kuznetsov Date: Thu, 7 Jan 2016 10:33:09 +0100 > Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add > VLAN ID to flow_keys")) introduced a performance regression in netvsc > driver. Is problem is, however, not the above mentioned commit but the > fact that netvsc_set_hash() function did some assumptions on the struct > flow_keys data layout and this is wrong. We need to extract the data we > need (src/dst addresses and ports) after the dissect. > > The issue could also be solved in a completely different way: as suggested > by Eric instead of our own homegrown netvsc_set_hash() we could use > skb_get_hash() which does more or less the same. Unfortunately, the > testing done by Simon showed that Hyper-V hosts are not happy with our > Jenkins hash, selecting the output queue with the current algorithm based > on Toeplitz hash works significantly better. > > Tested-by: Simon Xiao > Signed-off-by: Vitaly Kuznetsov Stop using this Toeplitz thing and just use the proper hash the stack is already calculating for you. There is no way this is faster, and the continued attempts to shoe-horn Toeplitz usage into this driver is resulting in incredibly ugly and rediculous code. I'm not applying any patches that further the use of Toeplitz as the hash function in this driver. You must use the clean, efficient, facilities the kernel has already for packet hashing. If every driver did what you guys are doing, we'd be in a heap of trouble, and I'm simply not going to allow this to continue any longer. Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout Date: Sun, 10 Jan 2016 17:25:58 -0500 (EST) Message-ID: <20160110.172558.367101858392871618.davem@davemloft.net> References: <1452159189-11473-1-git-send-email-vkuznets@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org, haiyangz@microsoft.com, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org To: vkuznets@redhat.com Return-path: In-Reply-To: <1452159189-11473-1-git-send-email-vkuznets@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" List-Id: netdev.vger.kernel.org From: Vitaly Kuznetsov Date: Thu, 7 Jan 2016 10:33:09 +0100 > Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add > VLAN ID to flow_keys")) introduced a performance regression in netvsc > driver. Is problem is, however, not the above mentioned commit but the > fact that netvsc_set_hash() function did some assumptions on the struct > flow_keys data layout and this is wrong. We need to extract the data we > need (src/dst addresses and ports) after the dissect. > > The issue could also be solved in a completely different way: as suggested > by Eric instead of our own homegrown netvsc_set_hash() we could use > skb_get_hash() which does more or less the same. Unfortunately, the > testing done by Simon showed that Hyper-V hosts are not happy with our > Jenkins hash, selecting the output queue with the current algorithm based > on Toeplitz hash works significantly better. > > Tested-by: Simon Xiao > Signed-off-by: Vitaly Kuznetsov Stop using this Toeplitz thing and just use the proper hash the stack is already calculating for you. There is no way this is faster, and the continued attempts to shoe-horn Toeplitz usage into this driver is resulting in incredibly ugly and rediculous code. I'm not applying any patches that further the use of Toeplitz as the hash function in this driver. You must use the clean, efficient, facilities the kernel has already for packet hashing. If every driver did what you guys are doing, we'd be in a heap of trouble, and I'm simply not going to allow this to continue any longer. Thanks.