Received: by 10.192.165.148 with SMTP id m20csp85330imm; Thu, 26 Apr 2018 16:32:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqbDxAGowGZOUzEqqSu5UDBDE2ofeBhds/ThP09+hbKVulrx1fjz0kNg2UF3JOn7D21tbEc X-Received: by 2002:a17:902:8c91:: with SMTP id t17-v6mr62719plo.182.1524785562562; Thu, 26 Apr 2018 16:32:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524785562; cv=none; d=google.com; s=arc-20160816; b=D7QGKM39iJuEuhjDyoT9WzSogCVieJjjUD+J/Yay/JwHVRV2wcIf1bCsw/IRcHkAmI HNtBtgUzuJLSlHYAdRHgnUbR2FBfWqKriuofiUB2yNDWGf0ot+RWBCwFI8jb23Og43qk MEnPWgfc+T+D37NDBlpKwQDhVZluyuNjoMPRTijCNHvMHbGNm6rUKDyZpvO00C6MfbBF bncxtx2Qk3WYuQHnYJANkI8IG2jugW7aDCgQREpk3j3d2/H+f35wdbEY8KwH1xei5u9S jUSyto6JhAd6m/GrKXZEwWxv2A/zyCj6jMuamFLlewGLaLOuQhBX5vjCqo8cDRbG86+H T87A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=gdBpW/o+J1CGD0+7fNXj/yDa+dgw49deGZdbM1XlF7k=; b=UwdQUYBQQMfTsroy0pRMB2y2BYdKE9Y9LhQzwovpam4TMuD/YiVxyLsOsDsUep0Y7N GbFVZ9ItALIU3YssnFCfI0D/EstCqY1GanA7EU//dFowdl4AiQXoPmUf3Raj5w9ga6Hi 60sWl0YzKjm60815oSbKLRetp6Hqi7t+0ZIANcwXI7stfah4W/9ZLBp16trGUXffsq54 2Yh4wM56+itwYZohlE2DzB0w3b4mlMYgLq9iRuq3r/oIHtUVL1+9JISAPqlLLplqC4Vu Quph4w4/rV+Hd0uujdwYygaC8a+G6ypHtOpazsuSgtick6ddDih31+k0q1RWSKz24XEJ cOTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dev-mellanox-co-il.20150623.gappssmtp.com header.s=20150623 header.b=dlGqhUkL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mellanox.co.il Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c14si22184pfe.29.2018.04.26.16.32.28; Thu, 26 Apr 2018 16:32:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@dev-mellanox-co-il.20150623.gappssmtp.com header.s=20150623 header.b=dlGqhUkL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mellanox.co.il Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756118AbeDZXbQ (ORCPT + 99 others); Thu, 26 Apr 2018 19:31:16 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:43975 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeDZXbO (ORCPT ); Thu, 26 Apr 2018 19:31:14 -0400 Received: by mail-lf0-f68.google.com with SMTP id g12-v6so67072lfb.10 for ; Thu, 26 Apr 2018 16:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dev-mellanox-co-il.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gdBpW/o+J1CGD0+7fNXj/yDa+dgw49deGZdbM1XlF7k=; b=dlGqhUkL3n2QhfPvRdu+RlfV4VEXJB6LpT0AGRdSQ+WzDLmBLFUUlR8pSjpG8Ycqsa DObJvbf40/jjYAGKoCMD/EpHKKnZCpOKNkmw+DgXsRCzfi8Wu0YeSkF0T+5D09duRdDN yrWFqABkWP/kvlSSYxfh5HmDaHsYecUHIscJh3ZZUNgF94UnmK/9ZeNezvB/WPK1Ogk9 1nkdAVxNzpepQP2kJH/btd2L49e+nuZHftRJ720ZhVGJB5tMi4dAVs7cVmzn1AN8D/iv jxzMRaUX4yFeZvHiGro2Ua01i1DQWnSwoqzsE0LWFLrbPu/qVAcxnWDsX+937pY1Ju7J ZUUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gdBpW/o+J1CGD0+7fNXj/yDa+dgw49deGZdbM1XlF7k=; b=j/ehAxb91ZbdUujE6OxXf5DUBx/5tUQTh3gjoGOAFetEypG5jbR8FIWvjdoUD+2tC5 P8C1VsENgEG6dNEoNY4xQRkPcTEVw1WgoBwbKkUx/mXrCGa9IL3j8LmFHPyO2F3Dwpbm p5KAOyUggAFACFnyibLk2xYc3TVFgxMJtJUHvSbpV0tq6FhtgEwRxnCHIioKiFpe/jF+ k5VqnoGvKHcvRbfyvV5m/QPiZEdLj1OUetj474bkZw976DpBnSwch5SEWb77zw8KXoSJ JH8JjEkuGe3ogKSH4mz28Wa8g7VgY/jk4b+rsQ/QZTRHOAczLMGCYMZhZ4qXh4S5U+nr ZTvw== X-Gm-Message-State: ALQs6tAU/ah5C5iOUkWRWAkUzVK6M05oS3kf+EJngzwZBAX88AuA4/6m m3hynnBUm91245bgStd5sFmGDQ1zBAN5YFxrsGUONw== X-Received: by 2002:a19:d14a:: with SMTP id i71-v6mr21613lfg.1.1524785472901; Thu, 26 Apr 2018 16:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:2947:0:0:0:0:0 with HTTP; Thu, 26 Apr 2018 16:30:52 -0700 (PDT) In-Reply-To: <5cd29779-fc70-930a-7060-ee3332c15558@oracle.com> References: <1524775057-8012-1-git-send-email-qing.huang@oracle.com> <5cd29779-fc70-930a-7060-ee3332c15558@oracle.com> From: Saeed Mahameed Date: Thu, 26 Apr 2018 16:30:52 -0700 Message-ID: Subject: Re: [PATCH] net/mlx5: report persistent netdev stats across ifdown/ifup commands To: Qing Huang Cc: Eran Ben Elisha , linux-kernel , RDMA mailing list , Linux Netdev List , Leon Romanovsky , Matan Barak , Saeed Mahameed Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 3:37 PM, Qing Huang wrote: > > > On 04/26/2018 02:50 PM, Saeed Mahameed wrote: >> >> On Thu, Apr 26, 2018 at 1:37 PM, Qing Huang wrote: >>> >>> Current stats collecting scheme in mlx5 driver is to periodically fetch >>> aggregated stats from all the active mlx5 software channels associated >>> with the device. However when a mlx5 interface is brought down(ifdown), >>> all the channels will be deactivated and closed. A new set of channels >>> will be created when next ifup command or a similar command is called. >>> Unfortunately the new channels will have all stats reset to 0. So you >>> lose the accumulated stats information. This behavior is different from >>> other netdev drivers including the mlx4 driver. In order to fix it, we >>> now save prior mlx5 software stats into netdev stats fields, so all the >>> accumulated stats will survive multiple runs of ifdown/ifup commands and >>> be shown correctly. >>> >>> Orabug: 27548610 I don't think we need this internal bug reference, let's remove it. >>> >>> Signed-off-by: Qing Huang >>> --- >> >> Hi Qing, >> >> I am adding Eran since he is currently working on a similar patch, >> He is also taking care of all cores/rings stats to make them >> persistent, so you won't have discrepancy between >> ethtool and ifconfig stats. >> >> I am ok with this patch, but this means Eran has to work his way around >> it. >> >> so we have two options: >> >> 1. Temporary accept this patch, and change it later with Eran's work. >> 2. Wait for Eran's work. >> >> I am ok with either one of them, please let me know. >> >> Thanks ! > > Hi Saeed, > > Any idea on rough ETA of Eran's stats work to be in upstream? If it will be All i know that it is planned for v4.18. > available soon, I think > we can wait a bit. If it will take a while to redesign the whole stats > scheme (for both ethtool and ifconfig), > maybe we can go with this incremental fix first? > Yes we can go with incremental fix, but let's fix the commit message as requested above and make the patch title prefix "net/mlx5e:" since this is a mlx5 netdev related change, not mlx5/core. also please see a comments below. Thanks, Saeed. > Thanks! > > >> >>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 30 >>> +++++++++++++++++++---- >>> 1 file changed, 25 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> index f1fe490..5d50e69 100644 >>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c >>> @@ -2621,6 +2621,23 @@ static void mlx5e_netdev_set_tcs(struct net_device >>> *netdev) >>> netdev_set_tc_queue(netdev, tc, nch, 0); >>> } >>> >>> +static void mlx5e_netdev_save_stats(struct mlx5e_priv *priv) >>> +{ >>> + struct net_device *netdev = priv->netdev; >>> + >>> + netdev->stats.rx_packets += priv->stats.sw.rx_packets; >>> + netdev->stats.rx_bytes += priv->stats.sw.rx_bytes; >>> + netdev->stats.tx_packets += priv->stats.sw.tx_packets; >>> + netdev->stats.tx_bytes += priv->stats.sw.tx_bytes; >>> + netdev->stats.tx_dropped += priv->stats.sw.tx_queue_dropped; >>> + >>> + priv->stats.sw.rx_packets = 0; >>> + priv->stats.sw.rx_bytes = 0; >>> + priv->stats.sw.tx_packets = 0; >>> + priv->stats.sw.tx_bytes = 0; >>> + priv->stats.sw.tx_queue_dropped = 0; Note: it is safe to do this here since writing to priv->stats.sw is currently done under priv->state_lock, Please add a comment to this function that it must be called under priv->state_lock >>> +} >>> + >> >> This means that we are now explicitly clearing channels stats on >> ifconfig down or switch_channels. >> and now after ifconfing down, ethtool will always show 0, before this >> patch it didn't. >> Anyway update sw stats function will always override them with the new >> channels stats next time we load new channels. >> so it is not that big of a deal. >> >> >>> static void mlx5e_build_channels_tx_maps(struct mlx5e_priv *priv) >>> { >>> struct mlx5e_channel *c; >>> @@ -2691,6 +2708,7 @@ void mlx5e_switch_priv_channels(struct mlx5e_priv >>> *priv, >>> netif_set_real_num_tx_queues(netdev, new_num_txqs); >>> >>> mlx5e_deactivate_priv_channels(priv); >>> + mlx5e_netdev_save_stats(priv); This function call doesn't have to be between deactivate and close, lets move it to after mlx5e_close_channels here and below to avoid confusion. also you need to accumulate what is left in the rings/channels stats, before calling mlx5e_close_channels, see mlx5e_grp_sw_update_stats. >>> mlx5e_close_channels(&priv->channels); >>> >>> priv->channels = *new_chs; >>> @@ -2770,6 +2788,7 @@ int mlx5e_close_locked(struct net_device *netdev) >>> >>> netif_carrier_off(priv->netdev); >>> mlx5e_deactivate_priv_channels(priv); >>> + mlx5e_netdev_save_stats(priv); >>> mlx5e_close_channels(&priv->channels); >>> >>> return 0; >>> @@ -3215,11 +3234,12 @@ static int mlx5e_setup_tc(struct net_device *dev, >>> enum tc_setup_type type, >>> stats->tx_packets = PPORT_802_3_GET(pstats, >>> a_frames_transmitted_ok); >>> stats->tx_bytes = PPORT_802_3_GET(pstats, >>> a_octets_transmitted_ok); >>> } else { >>> - stats->rx_packets = sstats->rx_packets; >>> - stats->rx_bytes = sstats->rx_bytes; >>> - stats->tx_packets = sstats->tx_packets; >>> - stats->tx_bytes = sstats->tx_bytes; >>> - stats->tx_dropped = sstats->tx_queue_dropped; >>> + stats->rx_packets = sstats->rx_packets + >>> dev->stats.rx_packets; >>> + stats->rx_bytes = sstats->rx_bytes + >>> dev->stats.rx_bytes; >>> + stats->tx_packets = sstats->tx_packets + >>> dev->stats.tx_packets; >>> + stats->tx_bytes = sstats->tx_bytes + >>> dev->stats.tx_bytes; >>> + stats->tx_dropped = sstats->tx_queue_dropped + >>> + dev->stats.tx_dropped; >>> } >>> >>> stats->rx_dropped = priv->stats.qcnt.rx_out_of_buffer; >>> -- >>> 1.8.3.1 >>> >