patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "Guo, Jia" <jia.guo@intel.com>
To: Igor Ryzhov <iryzhov@nfware.com>, dev <dev@dpdk.org>
Cc: dpdk stable <stable@dpdk.org>,
	"Xing, Beilei" <beilei.xing@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-stable] [PATCH] net/i40e: fix counters
Date: Tue, 24 Nov 2020 03:34:06 +0000	[thread overview]
Message-ID: <2ada7ab1daa242ae8e256b8432141d32@intel.com> (raw)
In-Reply-To: <CAF+s_Fw5hTj4RFYH96jih8Qa2Fs0NDPqUhXqyuAYqgmkkpAoZg@mail.gmail.com>

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 <iryzhov@nfware.com>
Sent: Friday, November 20, 2020 2:27 AM
To: dev <dev@dpdk.org>
Cc: dpdk stable <stable@dpdk.org>; Xing, Beilei <beilei.xing@intel.com>; Guo, Jia <jia.guo@intel.com>; Thomas Monjalon <thomas@monjalon.net>
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 <iryzhov@nfware.com<mailto:iryzhov@nfware.com>> 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<mailto:stable@dpdk.org>
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com<mailto:iryzhov@nfware.com>>
---
 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 void *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 = (uint64_t)I40E_READ_REG(hw, loreg);
-       new_data |= ((uint64_t)(I40E_READ_REG(hw, hireg) &
-                       I40E_16_BIT_MASK)) << I40E_32_BIT_WIDTH;
+       if (hw->device_id == I40E_DEV_ID_QEMU) {
+               new_data = (uint64_t)I40E_READ_REG(hw, loreg);
+               new_data |= ((uint64_t)(I40E_READ_REG(hw, hireg) &
+                               I40E_16_BIT_MASK)) << I40E_32_BIT_WIDTH;
+       } else {
+               new_data = I40E_READ_REG64(hw, loreg);
+       }

        if (!offset_loaded)
                *offset = new_data;
--
2.29.2

  reply	other threads:[~2020-11-24  3:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17  8:56 Igor Ryzhov
2020-11-19 18:27 ` Igor Ryzhov
2020-11-24  3:34   ` Guo, Jia [this message]
2020-11-24  8:24     ` Thomas Monjalon
2020-11-24  9:42       ` [dpdk-stable] [dpdk-dev] " Zhang, Qi Z
2020-11-24 10:07         ` Igor Ryzhov
2020-12-23  8:03 ` Zhang, Qi Z

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ada7ab1daa242ae8e256b8432141d32@intel.com \
    --to=jia.guo@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=iryzhov@nfware.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).