Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2697131pxa; Fri, 7 Aug 2020 19:07:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzue0On3AWlfwt8ORoDPKIvy4Q7IuGFQRYl5loriS3sI0wLtUrod3mM7vs2EBoJbETSTNxo X-Received: by 2002:a50:ee96:: with SMTP id f22mr11091154edr.243.1596852443507; Fri, 07 Aug 2020 19:07:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596852443; cv=none; d=google.com; s=arc-20160816; b=kv7fDMNOrKIYQR77F1H54YTBW/5vLBslaHcHjl7UaDbeU32jwQGztQhXzlgG1LXW1r sjGY90YQW/4Bmig01RtFlE0AFAu+bCXp4Yt6IhO3BoPtunjqdtrFZOUrzj7Mh10pu0eG THqTGOFCpCKqrdkVtMgAbJb24qH/ld9bZjx19n91PhYa/J0EGMLbzLN5uQu5wohkw4KX c1YWkO1PJoqrlSpIGjKZ0UWT6E7NbXgWM4D3FJgzCbKX9813+Gvf0v+HwNWfdZKtvCTI iciQPlZ0ZsraIyZnRlTUv70QbFqfU4rUzibSJWW7tiS0DRYAfqS3x8DmLlwWiaN1B/RR +8Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=RPwrLkQVeZxrmTY5UcyZKm3agUrLNuLjzJ2UJ88Lcic=; b=cYkZRnYyn3yt/vYrQxvjOnqOipW5m3qcFB8vg26bFJNWy8LT+5+NxeEyqnEg5fErUs TylnEObZd6TjJe8Zrkwejc13hld0slj6mY2VK4zO5UH2CoS6BXDnO86a6sM4mC2gmqKt 75jLmctHjfaQWWcNf0FUgvr6oUpB8fcTByTyJWYpKLsDSSNKpzl5fxpRt5kZyktI3eQ/ v8kTLGum5U+T3p2AAI1CnO+/TF9XlbKIQE5J8CizQZ/85HrAF8CkoscJ7WnRN3YMoqkV bJCt6SbZuRTlLmBZ6LCcGNBvcrErHIZVM3c3mosXJZs5ktQheTzYCSYG4tD9kTpN1AAy vTsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z7si7934874ede.225.2020.08.07.19.07.00; Fri, 07 Aug 2020 19:07:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726507AbgHHCGV (ORCPT + 99 others); Fri, 7 Aug 2020 22:06:21 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:47030 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726262AbgHHCGV (ORCPT ); Fri, 7 Aug 2020 22:06:21 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1k4EFV-008g5y-NR; Sat, 08 Aug 2020 04:06:17 +0200 Date: Sat, 8 Aug 2020 04:06:17 +0200 From: Andrew Lunn To: Jonathan Adams Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Greg KH , Jim Mattson , David Rientjes Subject: Re: [RFC PATCH 0/7] metricfs metric file system and examples Message-ID: <20200808020617.GD2028541@lunn.ch> References: <20200807212916.2883031-1-jwadams@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200807212916.2883031-1-jwadams@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > net/dev/stats/tx_bytes/annotations > DESCRIPTION net\ device\ transmited\ bytes\ count > CUMULATIVE > net/dev/stats/tx_bytes/fields > interface value > str int > net/dev/stats/tx_bytes/values > lo 4394430608 > eth0 33353183843 > eth1 16228847091 This is a rather small system. Have you tested it at scale? An Ethernet switch with 64 physical interfaces, and say 32 VLAN interfaces stack on top. So this one file will contain 2048 entries? And generally, you are not interested in one statistic, but many statistics. So you will need to cat each file, not just one file. And the way this is implemented: +static void dev_stats_emit(struct metric_emitter *e, + struct net_device *dev, + struct metric_def *metricd) +{ + struct rtnl_link_stats64 temp; + const struct rtnl_link_stats64 *stats = dev_get_stats(dev, &temp); + + if (stats) { + __u8 *ptr = (((__u8 *)stats) + metricd->off); + + METRIC_EMIT_INT(e, *(__u64 *)ptr, dev->name, NULL); + } +} means you are going to be calling dev_get_stats() for each file, and there are 23 files if i counted correctly. So dev_get_stats() will be called 47104 times, in this made up example. And this is not always cheap, these counts can be atomic. So i personally don't think netdev statistics is a good idea, i doubt it scales. I also think you are looking at the wrong set of netdev counters. I would be more interested in ethtool -S counters. But it appears you make the assumption that each object you are collecting metrics for has the same set of counters. This is untrue for network interfaces, where each driver can export whatever counters it wants, and they can be dynamic. Andrew