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.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 5EDDCC433E1 for ; Tue, 26 May 2020 15:45:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D326206D5 for ; Tue, 26 May 2020 15:45:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WFxRU/dX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730125AbgEZPp0 (ORCPT ); Tue, 26 May 2020 11:45:26 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:49277 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729309AbgEZPpZ (ORCPT ); Tue, 26 May 2020 11:45:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590507923; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=WFxRU/dXAN6kUGMa//XzU+8ee6lVIeUskhLksL+KpND2p2CGLRykLwk230HKo64n7ZFXyS Y3/KQAyVrgiyz7tRQmfkCA0oX8RohUGOiJQsHSYMMPM2HX4c7AtLxakfMFe+LZSEKTT84r xvyU2JnZ43b36N+ruXdRaCITOeXoP7M= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-25-xhhkL8r_PWqfEgnnDd8dmA-1; Tue, 26 May 2020 11:45:20 -0400 X-MC-Unique: xhhkL8r_PWqfEgnnDd8dmA-1 Received: by mail-wr1-f70.google.com with SMTP id z5so9926605wrt.17 for ; Tue, 26 May 2020 08:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=nRAIHQqe4MOem8mWzZ7d+7J/U/nrQxNmPFx7Z8Mp4PBx5A8qcQNNs+GpusJFTsABUc wAgs9/9xF4gMTj/QoROp7YNykWgUddudqaiXC6O0efIGF/Z8QjeHPp7Od6I7NbKLaDfL gWhoJT35faADUEI0B11jcC0EmcP6Ji8TqClPJ/uWYty+y2NhDroGnCHmLCinPi61+upB zdzvYSovdjdhaGj0ELpNZ2HiJObMutuD8WKHLwS2U9KCKwIy9+m3I4pNdEl5K+/KTU4Y /ZVoKyyDIdyEiC8qW/IAO0fi7PhIU80eg1FObNLHVNlWsn+SX3/UkQjIW9ZKTnw1EBZz sWhw== X-Gm-Message-State: AOAM532eHsUPleXfYZLQONon+9L29SxRoKWsUElOFqwsOnwSrb59K0Cn AiOkvMLs43pKQraq6gTc8SP0Ibft9qFR4dSeW/OXZEynLNHhNpvnjsQ/c/kXZLeQrHyzMtI4qg4 WsmuP7lGxNd6Adva6ORSLrMD1 X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr2590865wrx.231.1590507919725; Tue, 26 May 2020 08:45:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5If1uNgTKWEisUAJowYTPwcuzMOOow4nahat1ESbDjPkHGjhZwTTbQrIPi02UQ5LtAAq4hw== X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr2590848wrx.231.1590507919516; Tue, 26 May 2020 08:45:19 -0700 (PDT) Received: from localhost.localdomain ([194.230.155.118]) by smtp.gmail.com with ESMTPSA id u10sm32544wmc.31.2020.05.26.08.45.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 08:45:18 -0700 (PDT) Subject: Re: [PATCH v3 7/7] [not for merge] netstats: example use of stats_fs API To: Andrew Lunn Cc: kvm@vger.kernel.org, Christian Borntraeger , Paolo Bonzini , Jim Mattson , Alexander Viro , Emanuele Giuseppe Esposito , David Rientjes , Jonathan Adams , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org References: <20200526110318.69006-1-eesposit@redhat.com> <20200526110318.69006-8-eesposit@redhat.com> <20200526141605.GJ768009@lunn.ch> From: Emanuele Giuseppe Esposito Message-ID: <99217496-929f-ed3b-8e9e-bbd26d06e234@redhat.com> Date: Tue, 26 May 2020 17:45:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200526141605.GJ768009@lunn.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew > How do you atomically get and display a group of statistics? > > If you look at how the netlink socket works, you will see code like: > > do { > start = u64_stats_fetch_begin_irq(&cpu_stats->syncp); > rx_packets = cpu_stats->rx_packets; > rx_bytes = cpu_stats->rx_bytes; > .... > } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, start)); > > It will ensure that rx_packets and rx_bytes are consistent with each > other. If the value of the sequence counter changes while inside the > loop, the loop so repeated until it does not change. > > In general, hardware counters in NICs are the same. You tell it to > take a snapshot of the statistics counters, and then read them all > back, to give a consistent view across all the statistics. > > I've not looked at this new code in detail, but it looks like you have > one file per statistic, and assume each statistic is independent of > every other statistic. This independence can limit how you use the > values, particularly when debugging. The netlink interface we use does > not have this limitation. You're right, statistics are treated independently so what you describe is currently not supported. In KVM the utilization is more qualitative, so there isn't such problem. But as long as the interface is based on file access, the possibility of snapshotting might not be useful; however, it could still be considered to be added later together with the binary access. Jonathan, how is your metricfs handling this case? Thank you, Emanuele 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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 6AFD7C433E0 for ; Tue, 26 May 2020 15:48:56 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CCEFB20663 for ; Tue, 26 May 2020 15:48:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BoPFPvwT"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BoPFPvwT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCEFB20663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 49Wdfp1TFDzDqQY for ; Wed, 27 May 2020 01:48:50 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=207.211.31.120; helo=us-smtp-1.mimecast.com; envelope-from=eesposit@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=BoPFPvwT; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=BoPFPvwT; dkim-atps=neutral Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 49WdZz3QYczDqJc for ; Wed, 27 May 2020 01:45:29 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590507925; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=BoPFPvwTpWtXxNMFPTpvBdk46+hlxEqyKAg2w6CUGqkGLnRHKzp6xD6EywNSAmGjOlbEz+ h98j3/MlhOsvSHW00PhSAw3JXcylT6GddbnK5DN53Vwl1vcAGysaKCo30YoKD/TU8j8VwK jaTCMj6uL2UAtyZIh3VvUMYKaMRFo2I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590507925; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=BoPFPvwTpWtXxNMFPTpvBdk46+hlxEqyKAg2w6CUGqkGLnRHKzp6xD6EywNSAmGjOlbEz+ h98j3/MlhOsvSHW00PhSAw3JXcylT6GddbnK5DN53Vwl1vcAGysaKCo30YoKD/TU8j8VwK jaTCMj6uL2UAtyZIh3VvUMYKaMRFo2I= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-35-rfLh0eRaOnGwQRs8HbHalA-1; Tue, 26 May 2020 11:45:20 -0400 X-MC-Unique: rfLh0eRaOnGwQRs8HbHalA-1 Received: by mail-wr1-f69.google.com with SMTP id h12so9996599wrr.19 for ; Tue, 26 May 2020 08:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=N+URRBRjuF7RUk0qpfaWJFDdGgfUnbGAyILdscQJFdJxXdk9wtuxRkdp1Zeb7KollM njS0mnF6lBp7oArnH9+2tC0nhzOZ/vEkNwHFs5IFEdgZIdkvmd/E4VuS29QUw2mgOA/S 68AbJt5DkH08bpRYMCyFuik80BZJTCQYsMXXViT9DHx4/4Uj6ncE+LSmYONE1cExluMf lcOvCgeiUFPMYJT0qeYVs/hFO1K+6WlW5JYIfZcCMqwss5tyLLrIK1eHNxKjVbb7x3Kg fsGbon5SFx1evqcHIl3rIwhGg38M/93qQltP+wxKdfDTElKXfl1M48iJU4tGeEcKWp2r ifHg== X-Gm-Message-State: AOAM5336Y9SkRyFuQNX1aqiyDD4CwfIbYQNC4YRluXEqdAO0D8fo2z8/ wQIudqxql3IrS98vZCLNb0Zlv8et1wza5LjhQJPMTK9JABgajhNVj1fAkuSUYN3o763xHRexL5P i/F7IJvGE0M4ZSEU5yEk7javPOQ== X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr2590872wrx.231.1590507919727; Tue, 26 May 2020 08:45:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5If1uNgTKWEisUAJowYTPwcuzMOOow4nahat1ESbDjPkHGjhZwTTbQrIPi02UQ5LtAAq4hw== X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr2590848wrx.231.1590507919516; Tue, 26 May 2020 08:45:19 -0700 (PDT) Received: from localhost.localdomain ([194.230.155.118]) by smtp.gmail.com with ESMTPSA id u10sm32544wmc.31.2020.05.26.08.45.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 08:45:18 -0700 (PDT) Subject: Re: [PATCH v3 7/7] [not for merge] netstats: example use of stats_fs API To: Andrew Lunn References: <20200526110318.69006-1-eesposit@redhat.com> <20200526110318.69006-8-eesposit@redhat.com> <20200526141605.GJ768009@lunn.ch> From: Emanuele Giuseppe Esposito Message-ID: <99217496-929f-ed3b-8e9e-bbd26d06e234@redhat.com> Date: Tue, 26 May 2020 17:45:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200526141605.GJ768009@lunn.ch> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, Emanuele Giuseppe Esposito , linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, Jonathan Adams , Christian Borntraeger , Alexander Viro , David Rientjes , linux-fsdevel@vger.kernel.org, Paolo Bonzini , linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Jim Mattson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Andrew > How do you atomically get and display a group of statistics? > > If you look at how the netlink socket works, you will see code like: > > do { > start = u64_stats_fetch_begin_irq(&cpu_stats->syncp); > rx_packets = cpu_stats->rx_packets; > rx_bytes = cpu_stats->rx_bytes; > .... > } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, start)); > > It will ensure that rx_packets and rx_bytes are consistent with each > other. If the value of the sequence counter changes while inside the > loop, the loop so repeated until it does not change. > > In general, hardware counters in NICs are the same. You tell it to > take a snapshot of the statistics counters, and then read them all > back, to give a consistent view across all the statistics. > > I've not looked at this new code in detail, but it looks like you have > one file per statistic, and assume each statistic is independent of > every other statistic. This independence can limit how you use the > values, particularly when debugging. The netlink interface we use does > not have this limitation. You're right, statistics are treated independently so what you describe is currently not supported. In KVM the utilization is more qualitative, so there isn't such problem. But as long as the interface is based on file access, the possibility of snapshotting might not be useful; however, it could still be considered to be added later together with the binary access. Jonathan, how is your metricfs handling this case? Thank you, Emanuele 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 97016C433E0 for ; Tue, 26 May 2020 15:45:28 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5D51B20663 for ; Tue, 26 May 2020 15:45:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KV20nZvV"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MuDE1EeN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D51B20663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VVBZt6TRht7LSMYkC2f1DfHrPHLYwwupC1I+VNUUuqs=; b=KV20nZvVpC278VyjM+z8ZWVFI H+0oejfZIcw8tfR8pCFxWJqzGl42PJtubBHYz1yuoSnOwQn6Ut1djp7GC7BCk647RlNLPm7yJs3lV lOyXzCv4dU3KidgU/xbwraBdnJXbSHNLFuSKTqIvRK0NFosYxX/FOJXkQYh+QbvxvqdkBjwxeku/Q kCNpmRJt89DbfO7Q8OIZG+j2hSqhWGS6UhVjcM1jtqtjp2AWxEoLtERT3KaX96xLivDriPUejJh0F /6MzLFojLBIj23KVW3/8hTelIoUe2qQCgN/IBRT5VRx0vMsGsRmcr20lSlth8QqN2aEIkoGcLWv6S 45Hlkwbfw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jdblf-0002qm-9g; Tue, 26 May 2020 15:45:27 +0000 Received: from us-smtp-2.mimecast.com ([205.139.110.61] helo=us-smtp-delivery-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jdblb-0002pq-UF for linux-arm-kernel@lists.infradead.org; Tue, 26 May 2020 15:45:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590507922; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=MuDE1EeNGCQ7ZtyasjHIeRquVoyGlw4ms/cF48n+wazvpvZJXtfMaHWohfbEpb6eu/b5pd cagcXwYz82p5Nr22SwvYHKapCY9bDujsdyxeL5jbNE0kD6wB2awofKGhTvYwW4Qc8IF3qm sR+IEuKfj/j1E+CuQh5LmGbRLqBM3+E= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-110-wougYa4XPJORVXxG_DgfRA-1; Tue, 26 May 2020 11:45:21 -0400 X-MC-Unique: wougYa4XPJORVXxG_DgfRA-1 Received: by mail-wm1-f72.google.com with SMTP id b63so145860wme.1 for ; Tue, 26 May 2020 08:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Dt6LQHnd8XQKjoczzuKu5+J73yx/PTFTJmXrE029Qj0=; b=nQ4pFDa1+TddvvkrB2agRQsF6ZVd5g/QDGWbY+9v01ybhdgWqwu58dHSRFVxbFhryC Tsc9x75DuN8pmLkLrS8deA4d0VoB3SnH0H75eU5alb4auM49hgI0xS6RNskBrD947WDR blnnlZc8aRwsvd5euuO52yN2OC9iVq1ltQpzU5GjkJ472NClsNygHmQS2O7qJAOF+zWw a8eldPMsbFnt92fbHihTSNs4Chquol2GuWlpZML61wG08guyJI+Ipc8oj9lDdCt24Ty/ LcOLBzYhH1cJabbAohE0IVHcUXHeQeuetmMiNYklX3usxVI14NU4kES31/YIqXrYErMu 591A== X-Gm-Message-State: AOAM533DVOnBW3cMsyjsKJpQigJ1xr58kWchVD4ojMAjylRZOyV/Stbc fyJdj7Gke2unOjAyjFl5SSk5sEssN3a9HHQZOQizSvW9yWNTc2FCWoY+LnR/PFZHvXpXTK3KhNi 26Sd72TqZdimt763Tw9KF4zYGfTo9UcMjO9M= X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr2590858wrx.231.1590507919724; Tue, 26 May 2020 08:45:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5If1uNgTKWEisUAJowYTPwcuzMOOow4nahat1ESbDjPkHGjhZwTTbQrIPi02UQ5LtAAq4hw== X-Received: by 2002:a05:6000:1202:: with SMTP id e2mr2590848wrx.231.1590507919516; Tue, 26 May 2020 08:45:19 -0700 (PDT) Received: from localhost.localdomain ([194.230.155.118]) by smtp.gmail.com with ESMTPSA id u10sm32544wmc.31.2020.05.26.08.45.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 08:45:18 -0700 (PDT) Subject: Re: [PATCH v3 7/7] [not for merge] netstats: example use of stats_fs API To: Andrew Lunn References: <20200526110318.69006-1-eesposit@redhat.com> <20200526110318.69006-8-eesposit@redhat.com> <20200526141605.GJ768009@lunn.ch> From: Emanuele Giuseppe Esposito Message-ID: <99217496-929f-ed3b-8e9e-bbd26d06e234@redhat.com> Date: Tue, 26 May 2020 17:45:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200526141605.GJ768009@lunn.ch> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200526_084524_063326_2CCDC7CC X-CRM114-Status: GOOD ( 18.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, Emanuele Giuseppe Esposito , linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, Jonathan Adams , Christian Borntraeger , Alexander Viro , David Rientjes , linux-fsdevel@vger.kernel.org, Paolo Bonzini , linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, Jim Mattson Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Andrew > How do you atomically get and display a group of statistics? > > If you look at how the netlink socket works, you will see code like: > > do { > start = u64_stats_fetch_begin_irq(&cpu_stats->syncp); > rx_packets = cpu_stats->rx_packets; > rx_bytes = cpu_stats->rx_bytes; > .... > } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, start)); > > It will ensure that rx_packets and rx_bytes are consistent with each > other. If the value of the sequence counter changes while inside the > loop, the loop so repeated until it does not change. > > In general, hardware counters in NICs are the same. You tell it to > take a snapshot of the statistics counters, and then read them all > back, to give a consistent view across all the statistics. > > I've not looked at this new code in detail, but it looks like you have > one file per statistic, and assume each statistic is independent of > every other statistic. This independence can limit how you use the > values, particularly when debugging. The netlink interface we use does > not have this limitation. You're right, statistics are treated independently so what you describe is currently not supported. In KVM the utilization is more qualitative, so there isn't such problem. But as long as the interface is based on file access, the possibility of snapshotting might not be useful; however, it could still be considered to be added later together with the binary access. Jonathan, how is your metricfs handling this case? Thank you, Emanuele _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emanuele Giuseppe Esposito Date: Tue, 26 May 2020 15:45:17 +0000 Subject: Re: [PATCH v3 7/7] [not for merge] netstats: example use of stats_fs API Message-Id: <99217496-929f-ed3b-8e9e-bbd26d06e234@redhat.com> List-Id: References: <20200526110318.69006-1-eesposit@redhat.com> <20200526110318.69006-8-eesposit@redhat.com> <20200526141605.GJ768009@lunn.ch> In-Reply-To: <20200526141605.GJ768009@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Lunn Cc: kvm@vger.kernel.org, Christian Borntraeger , Paolo Bonzini , Jim Mattson , Alexander Viro , Emanuele Giuseppe Esposito , David Rientjes , Jonathan Adams , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org Hi Andrew > How do you atomically get and display a group of statistics? > > If you look at how the netlink socket works, you will see code like: > > do { > start = u64_stats_fetch_begin_irq(&cpu_stats->syncp); > rx_packets = cpu_stats->rx_packets; > rx_bytes = cpu_stats->rx_bytes; > .... > } while (u64_stats_fetch_retry_irq(&cpu_stats->syncp, start)); > > It will ensure that rx_packets and rx_bytes are consistent with each > other. If the value of the sequence counter changes while inside the > loop, the loop so repeated until it does not change. > > In general, hardware counters in NICs are the same. You tell it to > take a snapshot of the statistics counters, and then read them all > back, to give a consistent view across all the statistics. > > I've not looked at this new code in detail, but it looks like you have > one file per statistic, and assume each statistic is independent of > every other statistic. This independence can limit how you use the > values, particularly when debugging. The netlink interface we use does > not have this limitation. You're right, statistics are treated independently so what you describe is currently not supported. In KVM the utilization is more qualitative, so there isn't such problem. But as long as the interface is based on file access, the possibility of snapshotting might not be useful; however, it could still be considered to be added later together with the binary access. Jonathan, how is your metricfs handling this case? Thank you, Emanuele