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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 5AA6CC282C2 for ; Wed, 13 Feb 2019 03:28:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8DD5621B1A for ; Wed, 13 Feb 2019 03:28:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="KvLlV70R" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729646AbfBMD2W (ORCPT ); Tue, 12 Feb 2019 22:28:22 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:49384 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727346AbfBMD2V (ORCPT ); Tue, 12 Feb 2019 22:28:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1XxzJYmuOL4rmp3vOX/RHUF+qgwj3FKRlC+iN93hNW4=; b=KvLlV70Rq4pKQEApq9WPnGPyIY B7ztzCE6064qjR6F/kAjZ1/calGQO5pUc/LUNEF60wcttdU4djV/XEuC++MY+KWJG6sToTa5T2SEx Xpm6AwE/prqFOuP8tVBIHByarKJO2u65GET5l2C9v+/7vgms3+6BivERVFlYkQEjFFso=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1gtlDc-0002NZ-1m; Wed, 13 Feb 2019 04:28:16 +0100 Date: Wed, 13 Feb 2019 04:28:16 +0100 From: Andrew Lunn To: Tristram.Ha@microchip.com Cc: sergio.paracuellos@gmail.com, f.fainelli@gmail.com, pavel@ucw.cz, UNGLinuxDriver@microchip.com, netdev@vger.kernel.org Subject: Re: [PATCH v1 net-next 2/4] net: dsa: microchip: add MIB counter reading support Message-ID: <20190213032816.GE7527@lunn.ch> References: <1549598829-25970-1-git-send-email-Tristram.Ha@microchip.com> <1549598829-25970-3-git-send-email-Tristram.Ha@microchip.com> <20190209172249.GG30856@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > All of the MIB counters, except some that may be marked by driver, > do not get updated when the link is down, so it is a waste of time > to read them. Hi Tristram O.K, so make this clear in the code. Maybe rather than having this link_just_down, have the adjust link callback update the cached values for all counters? > My intention is the driver eventually reads the MIB counters at > least every second or faster so that the ethtool API called to show > MIB counters gets them from memory rather than starting a read > operation. The user expects to see the current counters, not some cached values. For me it is O.K. to frequently read the counters to prevent wrap around, but each ethtool call should update the counters before returning them to user space. > For simple switches that do not need to do anything special the MIB > read operation does not cause any issue except CPU load, for more > complicate switches that need to do some background operations too > many read operation can affect some critical functions. Sounds like a bad design of the switch, if reading statistics from it can upset its operation. You might want to consider rate limiting the ethtool call. Andrew