From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E39B3A04B1; Tue, 24 Nov 2020 10:43:07 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0580AC8F2; Tue, 24 Nov 2020 10:43:06 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 6095AC90C; Tue, 24 Nov 2020 10:43:03 +0100 (CET) IronPort-SDR: nvcPt8fT4sbllQbBYD4RA2UiL6sUSkoHJ4CQFNPeyFg0B4GY/USidat2V7nKruDznWTnrH9Z6m Zo3xk/Zr7iyQ== X-IronPort-AV: E=McAfee;i="6000,8403,9814"; a="159685649" X-IronPort-AV: E=Sophos;i="5.78,365,1599548400"; d="scan'208";a="159685649" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2020 01:43:01 -0800 IronPort-SDR: weieUMeIVv983Xldr9Hf4xa580ZmxP5EK+KXlPQ/1+F61BBUs8CLP7lYf44xlmhK5kp3tJVkoj 2pTEh73TYP5Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,365,1599548400"; d="scan'208";a="358761072" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga008.jf.intel.com with ESMTP; 24 Nov 2020 01:43:01 -0800 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 24 Nov 2020 01:43:00 -0800 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX602.ccr.corp.intel.com (10.109.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 24 Nov 2020 17:42:58 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.1713.004; Tue, 24 Nov 2020 17:42:58 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon , Igor Ryzhov , dev , "Guo, Jia" CC: dpdk stable , "Xing, Beilei" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH] net/i40e: fix counters Thread-Index: AQHWwhLS7TrL/kZVlEuOBYMggwYY6anWbECAgACaa3A= Date: Tue, 24 Nov 2020 09:42:58 +0000 Message-ID: <7958eb303ef7422bb1f7bac77b914d49@intel.com> References: <20201117085639.40307-1-iryzhov@nfware.com> <2ada7ab1daa242ae8e256b8432141d32@intel.com> <2232269.sFVF7DV9YO@thomas> In-Reply-To: <2232269.sFVF7DV9YO@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix counters X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: dev On Behalf Of Thomas Monjalon > Sent: Tuesday, November 24, 2020 4:25 PM > To: Igor Ryzhov ; dev ; Guo, Jia > > Cc: dpdk stable ; Xing, Beilei ; = Yigit, > Ferruh > Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix counters >=20 > I will follow the recommendation of Ferruh and i40e maintainers. > It is risky but it can be applied just before the release. I will suggest not to merge this patch in this release cycle, we need time = to fully test it and it can always be captured in following LTS release if = no issue be found. Thanks Qi >=20 >=20 > 24/11/2020 04:34, Guo, Jia: > > hi, igor ryzhov and Thomas > > > > Since this remain issue is report recently and we need to reproduce > > the issue and evaluate the patch and guaranty no side affect for other = case, so > I am not sure even I don't think it still have time window to hit 20.11. = But > whatever we have begin to check your patch for now on. What do you think = so? > > > > > > From: Igor Ryzhov > > Sent: Friday, November 20, 2020 2:27 AM > > To: dev > > Cc: dpdk stable ; Xing, Beilei > > ; Guo, Jia ; Thomas Monjalon > > > > Subject: Re: [PATCH] net/i40e: fix counters > > > > CC maintainers and Thomas. > > > > This fix should be 20.11. The issue is seen multiple times a day under = ~20G > traffic with stats collection once per second. > > > > Igor > > > > On Tue, Nov 17, 2020 at 11:56 AM Igor Ryzhov > > wrote: > > When low and high registers are read separately, this opens the door > > to a race condition: > > - low register is read > > - NIC updates the registers > > - high register is read > > > > Because of this, we may end up with an incorrect counter value. > > Let's read the registers in one shot, as it is done in Linux kernel > > since the introduction of the i40e driver. > > > > Fixes: 4861cde46116 ("i40e: new poll mode driver") > > Cc: stable@dpdk.org > > Signed-off-by: Igor Ryzhov > > > > > --- > > drivers/net/i40e/base/i40e_osdep.h | 10 ++++++++++ > > drivers/net/i40e/i40e_ethdev.c | 10 +++++++--- > > 2 files changed, 17 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/net/i40e/base/i40e_osdep.h > > b/drivers/net/i40e/base/i40e_osdep.h > > index 64b15e1b6138..ebd687240006 100644 > > --- a/drivers/net/i40e/base/i40e_osdep.h > > +++ b/drivers/net/i40e/base/i40e_osdep.h > > @@ -133,6 +133,14 @@ static inline uint32_t i40e_read_addr(volatile voi= d > *addr) > > return rte_le_to_cpu_32(I40E_PCI_REG(addr)); > > } > > > > +#define I40E_PCI_REG64(reg) rte_read64(reg) > > +#define I40E_PCI_REG64_ADDR(a, reg) \ > > + ((volatile uint64_t *)((char *)(a)->hw_addr + (reg))) static > > +inline uint64_t i40e_read64_addr(volatile void *addr) { > > + return rte_le_to_cpu_64(I40E_PCI_REG64(addr)); > > +} > > + > > #define I40E_PCI_REG_WRITE(reg, value) \ > > rte_write32((rte_cpu_to_le_32(value)), reg) #define > > I40E_PCI_REG_WRITE_RELAXED(reg, value) \ @@ -145,6 +153,8 @@ static > > inline uint32_t i40e_read_addr(volatile void *addr) #define > > I40E_WRITE_REG(hw, reg, value) \ > > I40E_PCI_REG_WRITE(I40E_PCI_REG_ADDR((hw), (reg)), (value)) > > > > +#define I40E_READ_REG64(hw, reg) > > +i40e_read64_addr(I40E_PCI_REG64_ADDR((hw), (reg))) > > + > > #define rd32(a, reg) i40e_read_addr(I40E_PCI_REG_ADDR((a), (reg))) > > #define wr32(a, reg, value) \ > > I40E_PCI_REG_WRITE(I40E_PCI_REG_ADDR((a), (reg)), (value)) > > diff --git a/drivers/net/i40e/i40e_ethdev.c > > b/drivers/net/i40e/i40e_ethdev.c index 74f4ac1f9d4e..53b1e9b9e067 > > 100644 > > --- a/drivers/net/i40e/i40e_ethdev.c > > +++ b/drivers/net/i40e/i40e_ethdev.c > > @@ -6451,9 +6451,13 @@ i40e_stat_update_48(struct i40e_hw *hw, { > > uint64_t new_data; > > > > - new_data =3D (uint64_t)I40E_READ_REG(hw, loreg); > > - new_data |=3D ((uint64_t)(I40E_READ_REG(hw, hireg) & > > - I40E_16_BIT_MASK)) << I40E_32_BIT_WIDTH; > > + if (hw->device_id =3D=3D I40E_DEV_ID_QEMU) { > > + new_data =3D (uint64_t)I40E_READ_REG(hw, loreg); > > + new_data |=3D ((uint64_t)(I40E_READ_REG(hw, hireg) & > > + I40E_16_BIT_MASK)) << > I40E_32_BIT_WIDTH; > > + } else { > > + new_data =3D I40E_READ_REG64(hw, loreg); > > + } > > > > if (!offset_loaded) > > *offset =3D new_data; > > -- > > 2.29.2 > > >=20 >=20 >=20 >=20