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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2A5EC433EF for ; Tue, 12 Apr 2022 17:37:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358306AbiDLRkA (ORCPT ); Tue, 12 Apr 2022 13:40:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358579AbiDLRjz (ORCPT ); Tue, 12 Apr 2022 13:39:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E73D562C89 for ; Tue, 12 Apr 2022 10:37:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7142161A0C for ; Tue, 12 Apr 2022 17:37:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A423AC385A8; Tue, 12 Apr 2022 17:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649785045; bh=KoBR7jg4rOAXy43fQYSmsZR2P0XGok1WXDJAEL/jR+0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XjImbaiz6vgKAhuqcLrGMcfQIyqjiPbl6BX0qyk82pYsS4IPLpR8bxvPEOkEHIfTn ur8EvYP2jvkVLWeu5dB1TxyM3eVDIglg81hr+tsccg1+KOGkDFlibMis0DxkasNpZb kpqA0u3GQdTHoukLIb5+Q/d8ZjlLqnxVDxv8Aox2Ik1mYkPDuY3jInstStMm2n1ZGN Lg0u3lumhVjFQeCTzcZFcywjnHFaxxDL/xc9hXRCQxO8majk/Ob2qnlPqXOWyVGVSp vd4iR7/G0nSVPoyarDmJH5XNESG5359+iSA9nH2Gl3oYVpKAGcOf3spqjB5zV3XUxR yLCYVDmUI/aJA== Date: Tue, 12 Apr 2022 10:37:24 -0700 From: Jakub Kicinski To: Ray Jui Cc: "David S. Miller" , netdev@vger.kernel.org Subject: Re: [RFC] Applicability of using 'txq_trans_update' during ring recovery Message-ID: <20220412103724.54924945@kernel.org> In-Reply-To: <1bdb8417-233d-932b-1dc0-c56042aedabd@broadcom.com> References: <1bdb8417-233d-932b-1dc0-c56042aedabd@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 12 Apr 2022 10:01:02 -0700 Ray Jui wrote: > Hi David/Jakub, > > I'd like to run through you on the idea of invoking 'txq_trans_update' > to update the last TX timestamp in the scenario where we temporarily > stop the TX queue to do some recovery work. Is it considered an > acceptable approach to prevent false positive triggering of TX timeout > during the recovery process? > > I know in general people use 'netif_carrier_off' during the process when > they reset/change the entire TX/RX ring set and/or other resources on > the Ethernet card. But in our particular case, we have another driver > running (i.e., RoCE) on top and setting 'netif_carrier_off' will cause a > significant side effect on the other driver (e.g., all RoCE QPs will be > terminated). In addition, for this special recovery work on our driver, > we are doing it on a per NAPI ring set basis while keeping the traffic > on other queues running. Using 'netif_carrier_off' will prevent traffic > running from all other queues that are not going through recovery. Can you use netif_device_detach() to mark the device as not present?