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,DKIM_SIGNED, DKIM_VALID,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 2F586C433ED for ; Sun, 2 May 2021 08:51:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ED608613C5 for ; Sun, 2 May 2021 08:51:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229754AbhEBIwM (ORCPT ); Sun, 2 May 2021 04:52:12 -0400 Received: from new1-smtp.messagingengine.com ([66.111.4.221]:47277 "EHLO new1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229613AbhEBIwM (ORCPT ); Sun, 2 May 2021 04:52:12 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 7B2A5580561; Sun, 2 May 2021 04:51:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 02 May 2021 04:51:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=nAMKrF +bnNdI3pkgmLhVLX5VUAzgUMzelRzJuMYbyMs=; b=BUCCTogNZaYRRxzyJztiVI xShJGneV54rIEyRyoSlS+fmXKMKcey9oOslb2tvsFHr5VTuXYNaJ7Wkdk15kKg+I UXPFbX/sEpkLPozL30ovUQF1Nd++3oO29OGeXtHzOeweopCe5SoW4mB/g6+iKmFv XQx3kuSsLHz+x2GEMld5s0kGTzDq3QyVtdZH+u7+ZPRtOTNV/BVa+ij9ccXdFbsz WDNfDZz6bqLxs60DgQq54JGerzqFjNv7r7K5a5lagbQjg9DkyDgNN8nAGxf0eHye yRht/U0kvcLiPz6kisiP3i6Qiqp/tDf7drGFmPfVYh65ry3AOfEE+O7Z8vMCcVXw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefuddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpeeuteegheehgeduueehffeltdegveelteeukeetteethfeltddvhfdtuedvueei feenucffohhmrghinhepnhhvihguihgrrdgtohhmpdgrrhhishhtrgdrtghomhenucfkph epudelfedrgeejrdduieehrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepihguohhstghhsehiughoshgthhdrohhrgh X-ME-Proxy: Received: from localhost (unknown [193.47.165.251]) by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 2 May 2021 04:51:18 -0400 (EDT) Date: Sun, 2 May 2021 11:51:15 +0300 From: Ido Schimmel To: Pavel Balaev Cc: "David S. Miller" , Jakub Kicinski , Jonathan Corbet , Hideaki YOSHIFUJI , David Ahern , Shuah Khan , Christophe JAILLET , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Ido Schimmel Subject: Re: [PATCH v6 net-next 1/3] net/ipv4: multipath routing: configurable seed Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Apr 30, 2021 at 02:36:49PM +0300, Pavel Balaev wrote: > On Thu, Apr 29, 2021 at 06:29:20PM +0300, Ido Schimmel wrote: > > On Wed, Apr 28, 2021 at 03:31:33PM +0300, Pavel Balaev wrote: > > This looks overly complex to me and I believe a lot of users will ask > > themselves why they need to specify a seed using two hex numbers > > separated by a comma. Looking at other implementations that already > > allow specifying the seed, it is specified as a single integer. > > > > 32-bit in Cumulus: > > https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-43/Layer-3/Routing/Equal-Cost-Multipath-Load-Sharing-Hardware-ECMP/#configure-a-hash-seed-to-avoid-hash-polarization > > > > Up to 16-bit in Arista: > > https://eos.arista.com/hashing-for-l2-port-channels-and-l3-ecmp/ > > > > I believe you chose this interface because of the structure of the > > SipHash key that is used for the multipath hash calculation. This is an > > internal implementation detail and should not determine the user > > interface. > > > > Looking at the history of the code, the flow dissector was migrated to > > SipHash in commit 55667441c84f ("net/flow_dissector: switch to > > siphash"). The motivating use case was flow label generation since these > > are sent on the wire together with the fields from which they were > > computed, not multipath hash calculation that also happens to rely on > > the flow dissector. > > > > Given the above, do you see a problem with having the user specify a > > 32-bit number for the multipath hash seed? Note that SipHash is still > > used and that the number can be used to fill the entire 128-bit space. > > Do you mean take 32-bit number from user and multiply it like this: > u32 key = val; > u64 key64; > memset(&key64, val, sizeof(u32)); > memset(&key64 + sizeof(u32), val, sizeof(u32)); > memset(seed.key[0], &key64, sizeof(u64)); > memset(seed.key[1], &key64, sizeof(u64)); > ? Something like that, yes. It's still only 32-bit of user input, but it can't hurt. Do you see a need to specify more than 32 bits for multipath hash seed when the purpose is to force the same seed on multiple machines?