From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 97E00A0501
for <public@inbox.dpdk.org>; Thu, 5 May 2022 18:57:55 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 89DFD4281C;
Thu, 5 May 2022 18:57:55 +0200 (CEST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com
(mail-co1nam11on2044.outbound.protection.outlook.com [40.107.220.44])
by mails.dpdk.org (Postfix) with ESMTP id 7269140042;
Thu, 5 May 2022 18:57:53 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=e4CQHe13nux9DG5UYnj0jTc066kYs6Kxo46umTogbhebn+4VsNiDEd7CQ5i0JZ13GtxbKYUaToU2wYKqnp1QsnTngeN76OuMdrAUTBdnM26yAbo5iQ0b+XnTW2i4FOR6AV9cA3R9/EDZheRvgOv/iZUPbNAkSH8KsdAI9Ewpp9wcz9h20F+DhT2Kc6BCYI7is6ag9iWhjMDTi+8u9veG47Xq8L3b4VW2izbA8NGL3eqUgj8mw+YYietKD26y/66DdB2Bcz8nr0sF1z8HDuyiAIrtd089TjY/vh58AR9KDBEFEA3R2oqv5KwxXv0IU6zARJeNMYh+U6gt2+y1N2CtQA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=59rLXpwpQYTgvOJw9GLI5Fc8HZYH3QBModpH2j4wCz8=;
b=TfWk95Zuip+tsQz7gTA8q/s4udvQwqOYFa+mlEc1YhjDknwoYHlO6B4qQLv2p5aVsW6E2eoszHILPiwrBEskCSi+BR0rDvh8gKxGdjcPHqwLlJaSW82CzVb2BsCeHExh0Ub522tVdSibC9EJ4jGbCsMSDloiG91pxfrG4EYNdqsCFUkRHP3ct44KrWtMxPJuAXIezNRS71I4lsnnBYxOXQoJsvcKqvXfRaHfN+JJ4sseTke+km2cdPcwH7s7EU35SluZcFvNo26T0FfHLyFGzg0/2FLg8DSxDwCCAoCrvrO6D5410ufmMJMOjZJ0mOl9Q1xXhB6rQgxkKNfel6SkgA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
149.199.80.198) smtp.rcpttodomain=networkplumber.org
smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none
header.from=xilinx.com; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=59rLXpwpQYTgvOJw9GLI5Fc8HZYH3QBModpH2j4wCz8=;
b=VlwjzV8JbTVlxLujatqhc7hUW69G6+zOK30dBsrz39YWVAaYGgY+JgxGfmTXFCIckTZ2ucoAUraHRIMydVIm5/nNYw1EfJ3XPYROt0f2Q4ozWULrbDHvB/ohJr/qF4R59HP1tpodJdf58gf4VMTc7Sgozx5llulsEhnO9pIf7Wk=
Received: from BN0PR04CA0108.namprd04.prod.outlook.com (2603:10b6:408:ec::23)
by DM6PR02MB5466.namprd02.prod.outlook.com (2603:10b6:5:7a::17) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.13; Thu, 5 May
2022 16:57:51 +0000
Received: from BN1NAM02FT010.eop-nam02.prod.protection.outlook.com
(2603:10b6:408:ec:cafe::46) by BN0PR04CA0108.outlook.office365.com
(2603:10b6:408:ec::23) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24 via Frontend
Transport; Thu, 5 May 2022 16:57:50 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198)
smtp.mailfrom=xilinx.com; dkim=none (message not signed)
header.d=none;dmarc=pass action=none header.from=xilinx.com;
Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates
149.199.80.198 as permitted sender) receiver=protection.outlook.com;
client-ip=149.199.80.198; helo=xir-pvapexch02.xlnx.xilinx.com;
Received: from xir-pvapexch02.xlnx.xilinx.com (149.199.80.198) by
BN1NAM02FT010.mail.protection.outlook.com (10.13.2.128) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.20.5227.15 via Frontend Transport; Thu, 5 May 2022 16:57:49 +0000
Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) by
xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2176.14; Thu, 5 May 2022 17:57:48 +0100
Received: from smtp.xilinx.com (172.21.105.198) by
xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server id
15.1.2176.14 via Frontend Transport; Thu, 5 May 2022 17:57:48 +0100
Envelope-to: stephen@networkplumber.org, longli@microsoft.com,
longli@linuxonhyperv.com, dev@dpdk.org, sthemmin@microsoft.com,
stable@dpdk.org
Received: from [10.71.119.95] (port=61260)
by smtp.xilinx.com with esmtp (Exim 4.90)
(envelope-from <ferruh.yigit@xilinx.com>)
id 1nmenU-0007GO-1D; Thu, 05 May 2022 17:57:48 +0100
Message-ID: <973e1c08-6fca-7664-72a3-0a25f5b73686@xilinx.com>
Date: Thu, 5 May 2022 17:57:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Subject: Re: [Patch v2] net/netvsc: report correct stats values
Content-Language: en-US
To: Stephen Hemminger <stephen@networkplumber.org>
CC: Long Li <longli@microsoft.com>, "longli@linuxonhyperv.com"
<longli@linuxonhyperv.com>, "dev@dpdk.org" <dev@dpdk.org>, Stephen Hemminger
<sthemmin@microsoft.com>, "stable@dpdk.org" <stable@dpdk.org>
References: <1648143948-17821-1-git-send-email-longli@linuxonhyperv.com>
<7f51e773-6ded-b736-fb02-5e3b391353b9@xilinx.com>
<20220426154524.49502217@hermes.local>
<PH7PR21MB326372E71F8198A6A74FBCA5CEC09@PH7PR21MB3263.namprd21.prod.outlook.com>
<924d7398-6c78-6318-52f3-d671edfc8aad@xilinx.com>
<PH7PR21MB326357EF0A378BA3CED0C0DACEC09@PH7PR21MB3263.namprd21.prod.outlook.com>
<04de7df6-3d4a-21e5-7be5-15f2ef88be16@xilinx.com>
<PH7PR21MB3263DCD502F8125A95AD5018CEC09@PH7PR21MB3263.namprd21.prod.outlook.com>
<99a629d6-642e-db25-eeaa-a9eceec577cb@xilinx.com>
<PH7PR21MB3263EF7E35243F5AB64BE9EFCEC39@PH7PR21MB3263.namprd21.prod.outlook.com>
<7809f41b-c21b-5ebe-d830-91015edb0cb8@xilinx.com>
<20220505094026.22e74f43@hermes.local>
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
In-Reply-To: <20220505094026.22e74f43@hermes.local>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c16789ae-7756-4f0c-0fde-08da2eb8631e
X-MS-TrafficTypeDiagnostic: DM6PR02MB5466:EE_
X-Microsoft-Antispam-PRVS: <DM6PR02MB546679636DD9719BC796702CD0C29@DM6PR02MB5466.namprd02.prod.outlook.com>
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: mEYZowBmbWL6FPywU7UyHGJ8gBMwYhRh/MWPv3G7BLtdP++E65EkXoaJOFz+U+3KLtEZLVvWAJtZBVWI9FLV0YGLmxGwQhMC0ru4qWQeB9Mh49AXm8qPpK/Ko6GbQ4m+mjtja8nKi12KrMkvPYEz7OMEsy4bPcCJ0rg8C6lrrFugAtjg9zIjyrG61B96SgHabxcF9QNpgCce1oDjwmhgIIXK2kG+Qm1LtrYemxrM5ygkrcdLHg0j8pRzbJeCQlYzOuJSqYHat4Cx9u5uNqOGGvnmViGdrUa4s6x9jH36MNoH/LslP1RNe0uRrZCq8u0TKx0u0UnRmjKpCeTHknOjnI40ExJ27qi1cFOSSlTLmN8sSSI4Vu5q6RndALaoNR89o16lg0/KgWsyLnLXGCBKAuYoax4+BfJ6tK0FuGWqeYvIjOHy2NdeaEJeQrHDKIYcFkX8FRumZ/YZjkCKSCoteEk/fvW3DDpEyIaS6r8z9vZAh7dRosS9aRtk6i/YYbXuknyd0QKoHEPqhfPOh9YXWz4X2YVWdscitmEnPcKFvxE0OiSG0i+43P6eruOsqA2rp8LGojemIlQtKuBXodFPRb+ytKU3ZzJNWBhsz2Tx/jDbqZAdBVCesuo1xFMgb1CDJabq0EYeB5VwvyWWc5+jPl30oTJxr6lIxhahCrQWxeoklEEt+zKfwkMo0sGjh2JVF1e4Ze+pJql9QhZ3+g/xvKXeYqYnZkw1wRcJvurdfTs+Jwrx2QFB6Aq5/M8SNTDzqy+tGF5YefZJey5sgTs2LNu+6LudkdJFeMtpHG/7XjA=
X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:;
IPV:CAL; SFV:NSPM; H:xir-pvapexch02.xlnx.xilinx.com;
PTR:unknown-80-198.xilinx.com; CAT:NONE;
SFS:(13230001)(4636009)(40470700004)(46966006)(36840700001)(508600001)(9786002)(2616005)(53546011)(8936002)(5660300002)(26005)(44832011)(40460700003)(2906002)(36756003)(36860700001)(356005)(31696002)(47076005)(426003)(7636003)(82310400005)(336012)(186003)(83380400001)(31686004)(4326008)(316002)(6916009)(8676002)(70586007)(54906003)(70206006)(50156003)(43740500002);
DIR:OUT; SFP:1101;
X-OriginatorOrg: xilinx.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2022 16:57:49.6558 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c16789ae-7756-4f0c-0fde-08da2eb8631e
X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198];
Helo=[xir-pvapexch02.xlnx.xilinx.com]
X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT010.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB5466
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
On 5/5/2022 5:40 PM, Stephen Hemminger wrote:
> On Thu, 5 May 2022 17:28:38 +0100
> Ferruh Yigit <ferruh.yigit@xilinx.com> wrote:
>
>> On 5/4/2022 7:38 PM, Long Li wrote:
>>>> Subject: Re: [Patch v2] net/netvsc: report correct stats values
>>>>
>>>> On 5/3/2022 9:48 PM, Long Li wrote:
>>>>>> Subject: Re: [Patch v2] net/netvsc: report correct stats values
>>>>>>
>>>>>> On 5/3/2022 8:14 PM, Long Li wrote:
>>>>>>>> Subject: Re: [Patch v2] net/netvsc: report correct stats values
>>>>>>>>
>>>>>>>> On 5/3/2022 7:18 PM, Long Li wrote:
>>>>>>>>>> Subject: Re: [Patch v2] net/netvsc: report correct stats values
>>>>>>>>>>
>>>>>>>>>> On Tue, 26 Apr 2022 22:56:14 +0100 Ferruh Yigit
>>>>>>>>>> <ferruh.yigit@xilinx.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>> if (i < RTE_ETHDEV_QUEUE_STAT_CNTRS) {
>>>>>>>>>>>> - stats->q_opackets[i] = txq->stats.packets;
>>>>>>>>>>>> - stats->q_obytes[i] = txq->stats.bytes;
>>>>>>>>>>>> + stats->q_opackets[i] += txq->stats.packets;
>>>>>>>>>>>> + stats->q_obytes[i] += txq->stats.bytes;
>>>>>>>>>>>
>>>>>>>>>>> This is per queue stats, 'stats->q_opackets[i]', in next
>>>>>>>>>>> iteration of the loop, 'i' will be increased and 'txq' will be
>>>>>>>>>>> updated, so as far as I can see the above change has no affect.
>>>>>>>>>>
>>>>>>>>>> Agree, that is why it was just assignment originally.
>>>>>>>>>
>>>>>>>>> The condition here is a little different. NETVSC is a master
>>>>>>>>> device with
>>>>>>>> another PMD running as a slave. When reporting stats values, it
>>>>>>>> needs to add the values from the slave PMD. The original code just
>>>>>>>> overwrites the values from its slave PMD.
>>>>>>>>
>>>>>>>> Where the initial values are coming from, 'hn_vf_stats_get()'?
>>>>>>>>
>>>>>>>> If 'hn_vf_stats_get()' fills the stats, what are the values kept in
>>>>>>>> 'txq-
>>>>>>> stats.*'
>>>>>>>> in above updated loop?
>>>>>>>
>>>>>>> Yes, hn_vf_stats_get() fills in the stats from the slave PMD.
>>>>>>> txq->stats
>>>>>> values are from the master PMD. Those values are different and
>>>>>> accounted separated from the values from the slave PMD.
>>>>>>
>>>>>> I see, since this is a little different than what most of the PMDs
>>>>>> do, can you please put a little more info to the commit log? Or
>>>>>> perhaps can add some comments to the code.
>>>>>
>>>>> Ok, will do.
>>>>>
>>>>>>
>>>>>> And still 'stats->rx_nombuf' change is not required right? If so can
>>>>>> you remove it in the next version?
>>>>>
>>>>> It is still needed. NETVSC unconditionally calls the slave PMD to receive
>>>> packets, even if it can't allocate a mbuf to receive a synthetic packet itself. The
>>>> accounting of rx_nombuf is valid because the synthetic packets (to NETVSC) and
>>>> VF packets (to slave PMD) are routed separately from Hyper-V.
>>>>
>>>> I am not referring to the "+=" update, my comment was because 'stats-
>>>>> rx_nombuf' is overwritten in 'rte_eth_stats_get()' [1].
>>>> Is it still required?
>>>
>>> Yes, it is still needed. NETVSC calls the rte_eth_stats_get() on its slave PMD first, and stats->rx_nombuf is updated (overwritten) for its slave PMD. Afte that, it needs to add to its own dev->data->rx_mbuf_alloc_failed back to stats->rx_nombuf.
>>>
>>
>> But its own stat also will be overwritten (not in PMD function, but in
>> ethdev layer).
>> 'stats->rx_nombuf' assignment in the PMD seems has no effect and can be
>> removed.
>>
>> I can't see how it is needed, can you please put a call stack to describe?
>
> This here:
>
>
> int
> rte_eth_stats_get(uint16_t port_id, struct rte_eth_stats *stats)
> {
> struct rte_eth_dev *dev;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
>
> if (stats == NULL) {
> RTE_ETHDEV_LOG(ERR, "Cannot get ethdev port %u stats to NULL\n",
> port_id);
> return -EINVAL;
> }
>
> memset(stats, 0, sizeof(*stats));
>
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->stats_get, -ENOTSUP);
> stats->rx_nombuf = dev->data->rx_mbuf_alloc_failed;
> return eth_err(port_id, (*dev->dev_ops->stats_get)(dev, stats));
> }
>
> Will fill in rx_nombuf from the current rx_mbuf_alloc_failed.
> But it happens before the PMD specific stats function.
>
I keep seeing the ethdev assignment as *after* the dev_ops, but it is
not [1], so code is OK as it is.
[1]
It seems assignment was after but it is fixed on the way:
Commit 53ecfa24fbcd ("ethdev: fix overwriting driver-specific stats")