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 ACCD2C433E0 for ; Sat, 13 Feb 2021 20:17:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6BEE464E35 for ; Sat, 13 Feb 2021 20:17:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229691AbhBMUQ6 (ORCPT ); Sat, 13 Feb 2021 15:16:58 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:48329 "EHLO wout3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229649AbhBMUQv (ORCPT ); Sat, 13 Feb 2021 15:16:51 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 96B86779; Sat, 13 Feb 2021 15:16:05 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 13 Feb 2021 15:16:06 -0500 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=gTsPkI JEkw/ab5dBAAYN9FyBUTJtf28GjjW9hPDu7EI=; b=WfoSzU3eiRJpPuFF/sHLeG RtIOOvCf7mCRLelgXqaGkqkVIGcrs5zZRBi4eOaWT+bfNo6SKTVL0KfJEvVrYN1V BPo+EuwdPCZaJmkNZwFau718BHm7RfbWaSYCW5luh0l9jlEVJAY/2P4bokNvN16S m7rB8QC/My07Rc8bLJPeWEOKmKT/2Jy+B/L0ED3WI1jWhIxcTbBLBOgMRkV1xnlo SdddtJksOyaN34jiZN7Nrqb4S6INHoTcaiFJIqvYLHRIcUXENWeyMUk0QAXMPy3t iYPyqCjbldVNq+JAt4d/HjmZf52a1sIVCtSaCElWxYrT/5ZkHrJ77etfDfRc8YQg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieefgddufedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedtffekkeefudffveegueejffejhfetgfeuuefgvedtieehudeuueekhfduheel teenucfkphepkeegrddvvdelrdduheefrdeggeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: from localhost (igld-84-229-153-44.inter.net.il [84.229.153.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F0E1108005C; Sat, 13 Feb 2021 15:16:04 -0500 (EST) Date: Sat, 13 Feb 2021 22:16:01 +0200 From: Ido Schimmel To: David Ahern Cc: Petr Machata , netdev@vger.kernel.org, David Ahern , "David S. Miller" , Jakub Kicinski , Ido Schimmel Subject: Re: [RFC PATCH 00/13] nexthop: Resilient next-hop groups Message-ID: <20210213201601.GA401513@shredder.lan> References: <20210213191619.GA399200@shredder.lan> <3ece022f-ec32-ab38-d2cf-a699c17bbcc7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ece022f-ec32-ab38-d2cf-a699c17bbcc7@gmail.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, Feb 13, 2021 at 12:17:54PM -0700, David Ahern wrote: > On 2/13/21 12:16 PM, Ido Schimmel wrote: > > On Sat, Feb 13, 2021 at 11:57:03AM -0700, David Ahern wrote: > >> On 2/8/21 1:42 PM, Petr Machata wrote: > >>> To illustrate the usage, consider the following commands: > >>> > >>> # ip nexthop add id 1 via 192.0.2.2 dev dummy1 > >>> # ip nexthop add id 2 via 192.0.2.3 dev dummy1 > >>> # ip nexthop add id 10 group 1/2 type resilient \ > >>> buckets 8 idle_timer 60 unbalanced_timer 300 > >>> > >>> The last command creates a resilient next hop group. It will have 8 > >>> buckets, each bucket will be considered idle when no traffic hits it for at > >>> least 60 seconds, and if the table remains out of balance for 300 seconds, > >>> it will be forcefully brought into balance. (If not present in netlink > >>> message, the idle timer defaults to 120 seconds, and there is no unbalanced > >>> timer, meaning the group may remain unbalanced indefinitely.) > >> > >> How did you come up with the default timer of 120 seconds? > > > > It is the default in the Cumulus Linux implementation (deployed for > > several years already), so we figured it should be OK. > > > > Add that to the commit log. OK, will add