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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5BF7C433F5 for ; Wed, 27 Oct 2021 18:12:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8852160C4A for ; Wed, 27 Oct 2021 18:12:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238431AbhJ0SOg (ORCPT ); Wed, 27 Oct 2021 14:14:36 -0400 Received: from new1-smtp.messagingengine.com ([66.111.4.221]:50185 "EHLO new1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236967AbhJ0SOe (ORCPT ); Wed, 27 Oct 2021 14:14:34 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 09E9B5803EA; Wed, 27 Oct 2021 14:12:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 27 Oct 2021 14:12: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=fm1; bh=j/RULZ tDpc+y/lprxEvKQj5w0p1vn9r8YHg3R7LWoz8=; b=MCPufT7RQPN3cp+7jiAfUB O0lBNoHNVx95HeZTrmsMUUO4cuFgyYJ9JTbPSn/wuwJEGMsTnqFQKdk4CFvKkuVn BaY2kmN+BWrinuvylKNQ2kMWOt7uNUgu7qU9VRJXfryC+W3/VtVkRufrbc1Q5o5e JOjhI+imtgIKA3dXlWyRxO3LjyiE4XXUC/ZoH/W/O48BbDRQcoQfB8o8NoBn034G Kfj+nyGEKjYALnis/ctOUlZ0E7+56B2KF0JRZRJPzBffOTc2mcsCYHfKriCw2OCG gVzO1E99yvbxqhkuFki5qGB6CqstfBqPa1cD5NReakDBlAf6Ei98jY8QMvRwUrWA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegtddguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepkfguohcu ufgthhhimhhmvghluceoihguohhstghhsehiughoshgthhdrohhrgheqnecuggftrfgrth htvghrnhepgfevgfevueduueffieffheeifffgjeelvedtteeuteeuffekvefggfdtudfg keevnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Oct 2021 14:12:03 -0400 (EDT) Date: Wed, 27 Oct 2021 21:11:59 +0300 From: Ido Schimmel To: Jakub Kicinski Cc: sundeep subbaraya , David Miller , netdev@vger.kernel.org, hariprasad , Geetha sowjanya , Sunil Kovvuri Goutham , Subbaraya Sundeep , Rakesh Babu , Saeed Mahameed , "anthony.l.nguyen@intel.com" , Jesse Brandeburg , Andrew Lunn Subject: Re: [EXT] Re: [net-next PATCH 1/2] octeontx2-pf: Add devlink param to init and de-init serdes Message-ID: References: <1635330675-25592-1-git-send-email-sbhatta@marvell.com> <1635330675-25592-2-git-send-email-sbhatta@marvell.com> <20211027083808.27f39cb0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211027100857.4d25544c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211027100857.4d25544c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Oct 27, 2021 at 10:08:57AM -0700, Jakub Kicinski wrote: > On Wed, 27 Oct 2021 22:13:32 +0530 sundeep subbaraya wrote: > > > On Wed, 27 Oct 2021 16:01:14 +0530 Subbaraya Sundeep wrote: > > > > From: Rakesh Babu > > > > > > > > The physical/SerDes link of an netdev interface is not > > > > toggled on interface bring up and bring down. This is > > > > because the same link is shared between PFs and its VFs. > > > > This patch adds devlink param to toggle physical link so > > > > that it is useful in cases where a physical link needs to > > > > be re-initialized. > > > > > > So it's a reset? Or are there cases where user wants the link > > > to stay down? > > > > There are cases where the user wants the link to stay down and debug. > > We are adding this to help customers to debug issues wrt physical links. > > Intel has a similar thing, they keep adding a ethtool priv flag called > "link-down-on-close" to all their drivers. This is the list I compiled the previous time we discussed it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3880bd159d431d06b687b0b5ab22e24e6ef0070 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5ec9e2ce41ac198de2ee18e0e529b7ebbc67408 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab4ab73fc1ec6dec548fa36c5e383ef5faa7b4c1 It seems that various drivers default to not shutting down the link upon ndo_stop(), but some users want to override it. I hit that too as it breaks ECMP (switch thinks the link is up). > Maybe others do this, too. It's time we added a standard API for > this. The new parameter sounds like a reset, but it can also be achieved by: # ethtool --set-priv-flags eth0 link-down-on-close on # ip link set dev eth0 down # ip link set dev eth0 up Where the first command is replaced by a more standard ethtool API.