From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 420162E839 for ; Tue, 9 Jan 2024 09:00:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=resnulli.us Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=resnulli.us Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=resnulli-us.20230601.gappssmtp.com header.i=@resnulli-us.20230601.gappssmtp.com header.b="LEAICaiX" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a28b1095064so289378266b.2 for ; Tue, 09 Jan 2024 01:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20230601.gappssmtp.com; s=20230601; t=1704790849; x=1705395649; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=TH0vBPQ7ZCebnduaCtu4eyZcvu00ZmUgY2nQfXfrFUg=; b=LEAICaiXk9EoYgo0v971JsF63IUyY84S++uHzr0TvkzXJADzJEnGZc1o9aSAlgdD9v e7UaPKyJrryuZi2ow760qU5/BNdNYPuqiXHSxytN1LMWSw5JNoMDYxtAQ7wKSSCdED3+ U6UIrX76sGCLs7ocrLpUeNe5Tj50W37YIqNdvUJjRqMOnlKSJ0Vo0QcHZFBNXO/V0SR/ N/lTbU5nUw9LRGgM5XoRszWmx8NFObWIpGXW7XtpleeTTqGwVi2yEnZ0oVHI2jU43apP urc5tTdsnZZmhGG39UQfSpwVUwz1rVv0KHRUrKGtqGaXstmqMjzAZnnePi/gFw9vbcQE KNbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704790849; x=1705395649; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TH0vBPQ7ZCebnduaCtu4eyZcvu00ZmUgY2nQfXfrFUg=; b=Phc4+CKV/bRiJg5K6AjfnYo+AEsX8tHF5Gs0M5O2hwV67bAgn5px+LtKQ/udDQAt1I Q6I78bNAhota+/4x7GpkrV7DJI0lgGPgM5B3oe07hbPg8IyPG5QZrOdrDl9j6ihOAHYc 934jBBQUHec5M31RlXpB17yKXsHMr8eqmZBgmhT8ZuxmkIREjHwj40QzEETtuYeCgDA9 0v/bxIEVePJ2m+sJSpwz5LpnPr2n6E+00VrXDcTC78vkb80YR6oRUmB4rEIwBt0lSljL VysAWguexzW02PSRux2r0Dbr8FAB6odSHRw1vBw8NtGvoeorqe5fEKJ1lvjO4pCfwCpc mW+g== X-Gm-Message-State: AOJu0YyER1jb6+GTiylE31G4pid9/9Qscv/S9EPGtNz9H6/IlLHzEG7Q mCcJ6RPnraQ/RFs4lIz0q9x/kiuzq6TEew== X-Google-Smtp-Source: AGHT+IH30ASTTUP+YrSZh8cY7YN/x67lugONlKiG1xXVGzwP0BKTaZg/KLQlKVoQA9pBxotlfy3L3Q== X-Received: by 2002:a17:907:7e84:b0:a27:efb8:6d51 with SMTP id qb4-20020a1709077e8400b00a27efb86d51mr194621ejc.228.1704790849166; Tue, 09 Jan 2024 01:00:49 -0800 (PST) Received: from localhost (host-213-179-129-39.customer.m-online.net. [213.179.129.39]) by smtp.gmail.com with ESMTPSA id bt11-20020a170906b14b00b00a27a766c6c8sm794046ejb.218.2024.01.09.01.00.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 01:00:48 -0800 (PST) Date: Tue, 9 Jan 2024 10:00:46 +0100 From: Jiri Pirko To: Jijie Shao Cc: yisen.zhuang@huawei.com, salil.mehta@huawei.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, shenjian15@huawei.com, wangjie125@huawei.com, liuyonglong@huawei.com, lanhao@huawei.com, wangpeiyang1@huawei.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V4 net-next 4/4] net: hns3: support dump pfc frame statistics in tx timeout log Message-ID: References: <20240105010119.2619873-1-shaojijie@huawei.com> <20240105010119.2619873-5-shaojijie@huawei.com> <00e5d6e2-168c-4887-8b6d-8498ebaafe6d@huawei.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e5d6e2-168c-4887-8b6d-8498ebaafe6d@huawei.com> Tue, Jan 09, 2024 at 09:19:48AM CET, shaojijie@huawei.com wrote: > >on 2024/1/5 17:55, Jiri Pirko wrote: >> > +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c >> > @@ -2871,8 +2871,10 @@ static bool hns3_get_tx_timeo_queue_info(struct net_device *ndev) >> > struct hns3_mac_stats mac_stats; >> > >> > h->ae_algo->ops->get_mac_stats(h, &mac_stats); >> > - netdev_info(ndev, "tx_pause_cnt: %llu, rx_pause_cnt: %llu\n", >> > - mac_stats.tx_pause_cnt, mac_stats.rx_pause_cnt); >> > + netdev_info(ndev, >> > + "tx_pause_cnt: %llu, rx_pause_cnt: %llu, tx_pfc_cnt: %llu, rx_pfc_cnt: %llu\n", >> > + mac_stats.tx_pause_cnt, mac_stats.rx_pause_cnt, >> > + mac_stats.tx_pfc_cnt, mac_stats.rx_pfc_cnt); >> Don't we have a better way to expose this? I mean, whenever there is a >> patch that extends the amount of text written in dmesg, it smells. >> We should rather reduce it. >> >In fact, we include this part of the statistics in the ethtool -S statistics. >However, if tx timeout occurs,the driver performs a reset attempt to recover >it. And the statistics are cleared after the reset. Therefore, pfc statistics >are added to tx timeout log to determine the timeout cause. Does not sound correct at all. You are basically forcing user to check the dmesg to understand the behaviour of stats he gets from ethtool. You can expose "reset"/"recover" counter through ethtool to expose this fact rather than dmesg print. Please don't add dmesg print. > >