From: "Jiang, JunyuX" <junyux.jiang@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
Igor Ryzhov <iryzhov@nfware.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "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: Mon, 21 Sep 2020 01:55:59 +0000 [thread overview]
Message-ID: <94aa88e605a4415e911201ed75c8b0e9@intel.com> (raw)
In-Reply-To: <aeeef274-451e-e07a-cc21-859052dbdafc@intel.com>
Hi Ferruh,
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, September 18, 2020 9:42 PM
> To: Igor Ryzhov <iryzhov@nfware.com>; Jiang, JunyuX
> <junyux.jiang@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; stable@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net/i40e: fix incorrect byte
> counters
>
> On 9/18/2020 10:23 AM, Igor Ryzhov wrote:
> > Hi,
> >
> > Your code will work only if stats are updated at least once between
> > two overflows.
> >
>
> In this case it will have problems in 'i40e_stat_update_48()' too.
> It seems there is no way to detect if the increase in stats is N or MAX_48+N
> by the software.
> And obviously there is no way to detect if the overflow occurred more than
> once.
>
> > So it's still up to the application to handle this properly. I think
> > it should be mentioned in the docs.
> >
>
> +1 to document.
>
I will fix in V3.
> > Igor
> >
> > On Fri, Sep 18, 2020 at 6:45 AM Jiang, JunyuX <junyux.jiang@intel.com
> > <mailto:junyux.jiang@intel.com>> wrote:
> >
> > Hi Ferruh,
> >
> > > -----Original Message-----
> > > From: Ferruh Yigit <ferruh.yigit@intel.com
> > <mailto:ferruh.yigit@intel.com>>
> > > Sent: Wednesday, September 16, 2020 8:31 PM
> > > To: Jiang, JunyuX <junyux.jiang@intel.com
> > <mailto:junyux.jiang@intel.com>>; dev@dpdk.org
> <mailto:dev@dpdk.org>
> > > Cc: Guo, Jia <jia.guo@intel.com <mailto:jia.guo@intel.com>>;
> > Xing, Beilei <beilei.xing@intel.com <mailto:beilei.xing@intel.com>>;
> > > stable@dpdk.org <mailto: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 <mailto:stable@dpdk.org>
> > > >
> > > > Signed-off-by: Junyu Jiang <junyux.jiang@intel.com
> > <mailto: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-21 1:56 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
2020-09-18 9:23 ` Igor Ryzhov
2020-09-18 13:42 ` Ferruh Yigit
2020-09-21 1:55 ` Jiang, JunyuX [this message]
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=94aa88e605a4415e911201ed75c8b0e9@intel.com \
--to=junyux.jiang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=iryzhov@nfware.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.