From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA0A8C433E0 for ; Fri, 22 Jan 2021 12:26:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FADC239D1 for ; Fri, 22 Jan 2021 12:26:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727758AbhAVM0c (ORCPT ); Fri, 22 Jan 2021 07:26:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727933AbhAVMZ0 (ORCPT ); Fri, 22 Jan 2021 07:25:26 -0500 Received: from orbyte.nwl.cc (orbyte.nwl.cc [IPv6:2001:41d0:e:133a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A2BFC06174A for ; Fri, 22 Jan 2021 04:24:34 -0800 (PST) Received: from n0-1 by orbyte.nwl.cc with local (Exim 4.94) (envelope-from ) id 1l2vUL-00005a-JL; Fri, 22 Jan 2021 13:24:29 +0100 Date: Fri, 22 Jan 2021 13:24:29 +0100 From: Phil Sutter To: Jamal Hadi Salim Cc: Stephen Hemminger , netdev@vger.kernel.org, Cong Wang , Jiri Pirko , Russell Stuart Subject: Re: tc: u32: Wrong sample hash calculation Message-ID: <20210122122429.GW3158@orbyte.nwl.cc> Mail-Followup-To: Phil Sutter , Jamal Hadi Salim , Stephen Hemminger , netdev@vger.kernel.org, Cong Wang , Jiri Pirko , Russell Stuart References: <20210118112919.GC3158@orbyte.nwl.cc> <8df2e0cc-3de4-7084-6859-df1559921fc7@mojatatu.com> <20210120152359.GM3158@orbyte.nwl.cc> <7d493e9f-23ee-34cf-fbdd-b13a4d3bb4af@mojatatu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d493e9f-23ee-34cf-fbdd-b13a4d3bb4af@mojatatu.com> Sender: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Jamal, On Fri, Jan 22, 2021 at 06:25:22AM -0500, Jamal Hadi Salim wrote: [...] > Is this always true though for all scenarios of key > 8b? Key size reduction algorithms simply differ, and before applying the divisor the key is reduced to an eight bit value. If the higher bytes are zero, the result is identical. So for some keys the differences are irrelevant. > And is there a pattern that can be deduced? Something like: 'broken = !!(key >> 8)'? ;) > My gut feel is user space is the right/easier spot to fix this > as long as it doesnt break the working setup of 8b. My motivation to write the initial email was that I don't like the kernel's key folding as it's basically just cutting off the extra bits. I am aware that fixing user space is easier, but better distribution of entries might be worth the extra effort. Given that you didn't point out any implications with changing u32's key folding in kernel space, I'll just give it a try. Thanks, Phil