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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 C371EC282C2 for ; Thu, 7 Feb 2019 16:23:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FB1B20863 for ; Thu, 7 Feb 2019 16:23:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="UMzuuJhg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726636AbfBGQXS (ORCPT ); Thu, 7 Feb 2019 11:23:18 -0500 Received: from mail-pl1-f178.google.com ([209.85.214.178]:42336 "EHLO mail-pl1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbfBGQXS (ORCPT ); Thu, 7 Feb 2019 11:23:18 -0500 Received: by mail-pl1-f178.google.com with SMTP id s1so144072plp.9 for ; Thu, 07 Feb 2019 08:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=KO+a5Yg0ZonogyaCblNilh0+UegHMKJxgQ+uxMqpXjA=; b=UMzuuJhgVUYgYbWl320spPhkjp6fQPYhIBXjyHm9x07UsBgbK8XQSRg6yA4zKoZ+gh lg1md7uM0D0HGTIl77maGq84LDivUto7SC7i1T/2Jig3eEstoIUGM1S2eTtKB0LDG/tq 8Z9Ws1iKzYWP4kWb/Kpzn8UCzEuAZygyKdg4N6y/oGjz1pQWrMZCQb7YaxfE4fUu/QO/ zQWhThYYPvwEvJnxTNlX6NuQLgekZwNCesV4rYLXoTnA+l3FB2zx0JDqqsfRbXuUj5z3 Ve4NrHNG2hBvfjKVHz0SyfsdYvymZP0KTH4n4DlFowNE8FkyFOAERDFONMIK1inIa9Qi Hw5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=KO+a5Yg0ZonogyaCblNilh0+UegHMKJxgQ+uxMqpXjA=; b=OXC7GnI955DyMEmSAGbm+sK2X6uBk6U1WsYXbf4xewZ+ZUes9fEYdLnYblYRz8VLjp uugZRNxR8P29o606yUxnwonMDbI3OU1T5JxeW+v53Lmi4vw8tQGNKwQVGHVWFpzjrpjh K8pqjimNzD3mx14lmWZkBVQF7YCMBLkAxO1jOOsmqAB5RYrE+270BlCvWXaI6jA6oihQ sS33UgNnyTxVUefGArhGzNscBNORgQDrgLY7jtAMvxmNwyNT6UbN+F65ymHbX6pxGK+Q 0q0uHeO7nasGkxMSv2tsNEnvXWV+Ks61svdFHm8waQiVrPMJfv0066pZYD7d3rJpkfSy kp6w== X-Gm-Message-State: AHQUAuZC0mcPwB1afhurLLYrs6I8HZV5L4dfKNiunRIXwZKos+lfMPCp wUs7V1LEuqabuLdWw++xQ37XZg== X-Google-Smtp-Source: AHgI3IYq6Ti9+ZQU400SxY8YG4r28jcXYIXtj8cP1nb4Eg2nUn4wab936tIg8k9OqIfcfphdwk9nSQ== X-Received: by 2002:a17:902:f20a:: with SMTP id gn10mr1566038plb.105.1549556597227; Thu, 07 Feb 2019 08:23:17 -0800 (PST) Received: from cakuba.netronome.com (c-73-223-131-122.hsd1.ca.comcast.net. [73.223.131.122]) by smtp.gmail.com with ESMTPSA id i28sm10678531pfi.171.2019.02.07.08.23.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Feb 2019 08:23:17 -0800 (PST) Date: Thu, 7 Feb 2019 08:23:11 -0800 From: Jakub Kicinski To: Florian Fainelli Cc: davem@davemloft.net, oss-drivers@netronome.com, netdev@vger.kernel.org, jiri@resnulli.us, andrew@lunn.ch, mkubecek@suse.cz, dsahern@gmail.com, simon.horman@netronome.com, jesse.brandeburg@intel.com, maciejromanfijalkowski@gmail.com, vasundhara-v.volam@broadcom.com, michael.chan@broadcom.com, shalomt@mellanox.com, idosch@mellanox.com Subject: Re: [RFC 00/14] netlink/hierarchical stats Message-ID: <20190207082311.58d991ed@cakuba.netronome.com> In-Reply-To: References: <20190128234507.32028-1-jakub.kicinski@netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 6 Feb 2019 12:12:39 -0800, Florian Fainelli wrote: > > By refresh control I mean the ability for user space to indicate how > > "fresh" values it expects. Sometimes reading the HW counters requires > > slow register reads or FW communication, in such cases drivers may cache > > the result. (Privileged) user space should be able to add a "not older > > than" timestamp to indicate how fresh statistics it expects. And vice > > versa, drivers can then also put the timestamp of when the statistics > > were last refreshed in the dump for more precise bandwidth estimation. > > Another thing that we cannot quite do with ethtool right now, at least > not easily, is something like the following use case. > > You have some filtering/classification capable hardware, and the HW can > count the number of times a rule has been hit/missed. The number of > rules programmed into the HW is dynamic and depends on use case so > dumping them all is not convenient for e.g.: hundreds/thousands of rules. That raises the inevitable question of what is the source of the rules i.e. which API has been used to configure them? > You would want to return only the rules that are active/enabled, and not > the full possible range of rules. With ethtool, this is not possible > because you have to define the strings first, and in a second call, you > are going to get the dump and fill in the data returned to user-space... Interesting, if the driver is caching the stats it can remember both last refresh and last change and return only the statistics which changed since time X. Would the "last changed" time stamp be of any use to user space? Probably not, right? > I will review more in depth, but the idea looks great so far. Thanks!