From: "Jiang, JunyuX" <junyux.jiang@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Guo, Jia" <jia.guo@intel.com>,
"Xing, Beilei" <beilei.xing@intel.com>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net/i40e: fix incorrect byte counters
Date: Fri, 18 Sep 2020 03:44:50 +0000 [thread overview]
Message-ID: <bef14cf2672a46408645074542fc11c4@intel.com> (raw)
In-Reply-To: <295e61ad-cbc5-3fbe-c996-c3f9a11b34d6@intel.com>
Hi Ferruh,
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Wednesday, September 16, 2020 8:31 PM
> To: Jiang, JunyuX <junyux.jiang@intel.com>; dev@dpdk.org
> Cc: Guo, Jia <jia.guo@intel.com>; Xing, Beilei <beilei.xing@intel.com>;
> stable@dpdk.org
> Subject: Re: [dpdk-stable] [PATCH v2] net/i40e: fix incorrect byte counters
>
> On 9/16/2020 2:51 AM, Junyu Jiang wrote:
> > This patch fixed the issue that rx/tx bytes overflowed
>
> "Rx/Tx statistics counters overflowed"?
>
Yes, the rx_bytes and tx_bytes counter in X710 cards is 48-bit long, if keep sending packets for a log time, the register will overflow.
> > on 48 bit limitation by enlarging the limitation.
> >
> > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Junyu Jiang <junyux.jiang@intel.com>
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 47
> ++++++++++++++++++++++++++++++++++
> > drivers/net/i40e/i40e_ethdev.h | 9 +++++++
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 563f21d9d..4d4ea9861 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -3073,6 +3073,13 @@ i40e_update_vsi_stats(struct i40e_vsi *vsi)
> > i40e_stat_update_48(hw, I40E_GLV_BPRCH(idx),
> I40E_GLV_BPRCL(idx),
> > vsi->offset_loaded, &oes->rx_broadcast,
> > &nes->rx_broadcast);
> > + /* enlarge the limitation when rx_bytes overflowed */
> > + if (vsi->offset_loaded) {
> > + if (I40E_RXTX_BYTES_LOW(vsi->old_rx_bytes) > nes-
> >rx_bytes)
> > + nes->rx_bytes += (uint64_t)1 << I40E_48_BIT_WIDTH;
> > + nes->rx_bytes += I40E_RXTX_BYTES_HIGH(vsi-
> >old_rx_bytes);
> > + }
> > + vsi->old_rx_bytes = nes->rx_bytes;
>
>
> Can you please describe this logic? (indeed better to describe it in the
> commit log)
>
> 'nes->rx_bytes' is diff in the stats register since last read.
> 'old_rx_bytes' is the previous stats diff.
>
> Why/how "I40E_RXTX_BYTES_LOW(vsi->old_rx_bytes) > nes->rx_bytes" has
> a meaning? Isn't this very depends on the read frequency?
>
> I guess I am missing something but please help me understand.
>
This patch fixes the issue of rx/tx bytes counter register overflow:
The counter register in i40e is 48-bit long, when overflow, nes->rx_bytes becomes less than old_rx_bytes, the correct value of nes->rx_bytes should be plused 1 << 48.
Use I40E_RXTX_BYTES_HIGH() to remember the MSB, nes->rx_bytes plus the MSB is the correct value, So that using uint64_t to enlarge the 48 bit limitation of register .
> Also can you please confirm the initial value of the "vsi->offset_loaded" is
> correct.
>
offset_loaded will be true when get statistics of port and offset_loaded will be false when reset or clear the statistics,
so if offset_loaded is false, shouldn't to calculate the value of nes->rx_bytes, it will be 0.
> <....>
>
> > @@ -282,6 +282,9 @@ struct rte_flow {
> > #define I40E_ETH_OVERHEAD \
> > (RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN +
> I40E_VLAN_TAG_SIZE * 2)
> >
> > +#define I40E_RXTX_BYTES_HIGH(bytes) ((bytes) & ~I40E_48_BIT_MASK)
> > +#define I40E_RXTX_BYTES_LOW(bytes) ((bytes) & I40E_48_BIT_MASK)
> > +
>
> HIGH/LOW is a little misleading, for 64Bits it sounds like it is getting low 32 bits
> and high 32 bits, can you please clarify macro masks out
> 48/16 bits.
>
Yes, I will change the macro name in V3.
>
> > struct i40e_adapter;
> > struct rte_pci_driver;
> >
> > @@ -399,6 +402,8 @@ struct i40e_vsi {
> > uint8_t vlan_anti_spoof_on; /* The VLAN anti-spoofing enabled */
> > uint8_t vlan_filter_on; /* The VLAN filter enabled */
> > struct i40e_bw_info bw_info; /* VSI bandwidth information */
> > + uint64_t old_rx_bytes;
> > + uint64_t old_tx_bytes;
>
> 'prev' seems better naming than 'old', what do you think renaming
> 'old_rx_bytes' -> 'prev_rx_bytes' (for all variables)?
Yes, it's better, I will fix it in V3.
next prev parent reply other threads:[~2020-09-18 3:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 1:54 [dpdk-dev] [PATCH] net/i40e: fix incorrect byte counters Junyu Jiang
2020-09-10 2:18 ` [dpdk-dev] [dpdk-stable] " Han, YingyaX
2020-09-10 5:58 ` Guo, Jia
2020-09-10 6:45 ` Jiang, JunyuX
2020-09-16 1:51 ` [dpdk-dev] [PATCH v2] " Junyu Jiang
2020-09-16 2:39 ` [dpdk-dev] [dpdk-stable] " Han, YingyaX
2020-09-16 5:21 ` [dpdk-dev] " Guo, Jia
2020-09-16 5:50 ` Zhang, Qi Z
2020-09-16 12:30 ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2020-09-18 3:44 ` Jiang, JunyuX [this message]
2020-09-18 9:23 ` Igor Ryzhov
2020-09-18 13:42 ` Ferruh Yigit
2020-09-21 1:55 ` Jiang, JunyuX
2020-09-18 13:37 ` Ferruh Yigit
2020-09-21 9:59 ` [dpdk-dev] [PATCH v3] " Junyu Jiang
2020-09-21 11:41 ` Ferruh Yigit
2020-09-22 7:37 ` [dpdk-dev] [PATCH v4] " Junyu Jiang
2020-09-22 9:06 ` Ferruh Yigit
2020-09-22 9:19 ` [dpdk-dev] [PATCH v5] " Junyu Jiang
2020-09-22 12:59 ` 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=bef14cf2672a46408645074542fc11c4@intel.com \
--to=junyux.jiang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jia.guo@intel.com \
--cc=stable@dpdk.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.