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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 0BFDAC433B4 for ; Mon, 19 Apr 2021 05:48:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D60006113C for ; Mon, 19 Apr 2021 05:48:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232880AbhDSFsf (ORCPT ); Mon, 19 Apr 2021 01:48:35 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:33657 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230392AbhDSFsf (ORCPT ); Mon, 19 Apr 2021 01:48:35 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 94D235C039E; Mon, 19 Apr 2021 01:48:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 19 Apr 2021 01:48:05 -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=j/e8a3 qQql0tN+k4Xa4i1asqnsgycUpoWvwOCFIwSSk=; b=eyAcjb4Yvbz8vAnxl3C21u VA/IUTxU8Ntq6olGvHYf9e5hk/pK2gtub1siRav7RzO7NjCsvDpL49wjYX0qQwPQ D5EZhoKYRqSZDwTgjHhAN2rdRikptTm+7Ny9Ly1AEvw5C78vwlYVPtbaacFmttx5 pIpGf8YKaxXSrHPYw7L5dvRMcbf6tZX8A/AIkyFJP1AUBxroQln/CqM4GfbYmp2P JtaVqm6ne+yyhti5w2PGpjhCbgaRPtoPq3E3rX8IpkNPMewWRRa14mQWJtCGg8vd GK9sIVfzdq6cVuzlk1f34PaMT/tkoZy9wgA5D6x+Wf1P8o5DVw8S9PC2HbnCy2gw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtvddgudeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcu ufgthhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrth htvghrnheptdffkeekfeduffevgeeujeffjefhtefgueeugfevtdeiheduueeukefhudeh leetnecukfhppeekgedrvddvledrudehfedrudekjeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: from localhost (igld-84-229-153-187.inter.net.il [84.229.153.187]) by mail.messagingengine.com (Postfix) with ESMTPA id C4C6E108005B; Mon, 19 Apr 2021 01:48:04 -0400 (EDT) Date: Mon, 19 Apr 2021 08:48:01 +0300 From: Ido Schimmel To: David Ahern Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org, petrm@nvidia.com, mlxsw@nvidia.com, Ido Schimmel Subject: Re: [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier Message-ID: References: <20210416155535.1694714-1-idosch@idosch.org> <20210416155535.1694714-2-idosch@idosch.org> <91838deb-c82d-444e-6a19-3926aeff87f2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91838deb-c82d-444e-6a19-3926aeff87f2@gmail.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Apr 18, 2021 at 10:06:41AM -0700, David Ahern wrote: > On 4/16/21 8:55 AM, Ido Schimmel wrote: > > From: Ido Schimmel > > > > Currently, a multi-part nexthop dump is restarted based on the number of > > nexthops that have been dumped so far. This can result in a lot of > > nexthops not being dumped when nexthops are simultaneously deleted: > > > > # ip nexthop | wc -l > > 65536 > > # ip nexthop flush > > Dump was interrupted and may be inconsistent. > > Flushed 36040 nexthops > > # ip nexthop | wc -l > > 29496 > > > > Instead, restart the dump based on the nexthop identifier (fixed number) > > of the last successfully dumped nexthop: > > > > # ip nexthop | wc -l > > 65536 > > # ip nexthop flush > > Dump was interrupted and may be inconsistent. > > Flushed 65536 nexthops > > # ip nexthop | wc -l > > 0 > > > > Reported-by: Maksym Yaremchuk > > Tested-by: Maksym Yaremchuk > > Signed-off-by: Ido Schimmel > > Reviewed-by: Petr Machata > > --- > > net/ipv4/nexthop.c | 14 ++++++-------- > > 1 file changed, 6 insertions(+), 8 deletions(-) > > > > Reviewed-by: David Ahern Thanks > > Any reason not to put this in -net with a Fixes tag? I put it in the cover letter: "Targeting at net-next since this use case never worked, the flow is pretty obscure and such a large number of nexthops is unlikely to be used in any real-world scenario."